From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 01 May 2025 23:47:47 -0700 Received: from mail-yw1-f183.google.com ([209.85.128.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uAkBW-0004ra-3l for bitcoindev@gnusha.org; Thu, 01 May 2025 23:47:47 -0700 Received: by mail-yw1-f183.google.com with SMTP id 00721157ae682-7080c0fe7b5sf24957077b3.2 for ; Thu, 01 May 2025 23:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1746168460; x=1746773260; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=PXWNzsXT0wGUfALMLcPZonPM3/S/H7jLcyi4VylVjPY=; b=oLm2rCV1aIlqnm6jftUEhnDgYAU+wqQhAI0EJFcHFMyvNBJjdTRkRHmKbtZ4yj5MuV jDOZUck5P7wZ71F7AkOSXq2KjCEsQu8jXCF33Kl8cKyPkTVDRcYWruGXz38da9lqYEX8 8i32PX6q62vUiH7hsoUDjAyF7KUVhjj7oimoJHwhXUJksW4hc04A33Zk2rtkS66NbIPs 3ekOuwWBri2aVuL6OB9RQGjmUuUVjz9xmKN0IEtxhVGINGgJ4hcZSmbCV6Zr7pdUINyp c/ZxKcSSpWiMAh7bKGrbqztHExgkGW6HJEHdTz8ZpooM0TKvcWKdmVP6j8+jTLYjXSr5 Xzvw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746168460; x=1746773260; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=PXWNzsXT0wGUfALMLcPZonPM3/S/H7jLcyi4VylVjPY=; b=KwyXnn7Zg4QPo+R70iWr1sEO3jXxViX6jIQxOQiGJZOIj9NhMviwdUBFYIPOnc7oPe rhhollQbcCoZrRGA7wekQ4Lq2L1FQhRKj486TLa+GOXYZHlFbiD3Y/GAoSFqZOzd7U/B NpGXbw7KQANqTSeT5mBHLmWoTCuodQDHRKt+f/MFS/UWsFDH3c44zD3oZcG9DqwqrKJ5 W40FuhrCSXj5xVOzZMS4b8h56r4s+EYwA6Y4ai9afWYdRSORFiZW6g4NQKKv1MIA3M5B B8MN9ThaM0n/bBp0jgHPfXIGTPgDfiUxpuwYl1+XD7gMINdPBCUtjZKxOfRTTfT8v5oq dAdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746168460; x=1746773260; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=PXWNzsXT0wGUfALMLcPZonPM3/S/H7jLcyi4VylVjPY=; b=gN7hqA4OyE3v42L7+vd37Ln019tFV+dCEK13Vne2W7NJFvMaYoP+CGglSsNNByXsLy zQcmTY6zMCZu9EBxhv9NZfDa2CQoaK3rxqYfINsCBI5tzJiVBve3jnJRMaUV00D7xsY3 75G8zjAVecrCPnKnbzwkCImplI02165X0Syw1n9YYMUxtJIJzlq1dzNB4Y7mFP28Jhhf XMS+Nio1AQV4yY9s068EAWZ5ffcIuuNN5xqXqhDJFzBH+0m9Neow4jGZBICmi8wQLFim PaAcnm9o5D+HIMaspaLpvRFlWCEaFP949kUhdzr7Fq9FSYf0l5uN/ovwGsxQvchFfBga WfDg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXn0+wMfKXl4d5ANOEV45uYcRtm0ARb/0PhrdZ5DDiFner8Nb6aJFyakG2jOZEQMq2TGg9Qr66mUHlq@gnusha.org X-Gm-Message-State: AOJu0YyJYJs0qzxo1abW4fkFJ/Gtg99GfoNKKuQwAfNOYVxghPII8Gyc LTcJk8a/tdG+7+bCnyav317n232I5MOfHro+3zgISV+E5JUZYeLp X-Google-Smtp-Source: AGHT+IG4A9k6amb5/P6DCObjVJmBkprBKhVD9/mR2j65U9Nnpp39h9+5mcNgMoHXxY8qlrlA2bg/yw== X-Received: by 2002:a05:6902:2291:b0:e74:c854:6fe2 with SMTP id 3f1490d57ef6-e75656273f5mr2570051276.33.1746168459849; Thu, 01 May 2025 23:47:39 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBH89Rwiua9kpQmZD2iS4mHCmL3Hq4pZXhgipnAtNvHHUg== Received: by 2002:a25:f604:0:b0:e74:756e:8301 with SMTP id 3f1490d57ef6-e74d95944ddls95324276.0.-pod-prod-03-us; Thu, 01 May 2025 23:47:34 -0700 (PDT) X-Received: by 2002:a05:690c:4903:b0:6fd:47a7:3fb2 with SMTP id 00721157ae682-708cede9337mr27923227b3.24.1746168454789; Thu, 01 May 2025 23:47:34 -0700 (PDT) Received: by 2002:a81:d448:0:b0:706:b535:945d with SMTP id 00721157ae682-708cfda3e37ms7b3; Thu, 1 May 2025 23:29:36 -0700 (PDT) X-Received: by 2002:a05:690c:6813:b0:6fb:a696:b23b with SMTP id 00721157ae682-708cee15433mr24373547b3.33.1746167375470; Thu, 01 May 2025 23:29:35 -0700 (PDT) Date: Thu, 1 May 2025 23:29:35 -0700 (PDT) From: Greg Maxwell To: Bitcoin Development Mailing List Message-Id: <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: Relax OP_RETURN standardness restrictions MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_28524_2014695618.1746167375125" X-Original-Sender: gmaxwell@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_28524_2014695618.1746167375125 Content-Type: multipart/alternative; boundary="----=_Part_28525_854370742.1746167375125" ------=_Part_28525_854370742.1746167375125 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thursday, April 17, 2025 at 7:09:23=E2=80=AFPM UTC Antoine Poinsot wrote= : Since the restrictions on the usage of OP_RETURN outputs encourage harmful= =20 practices while being ineffective in deterring unwanted usage, i propose to= =20 drop them.=20 The situation is even somewhat worse than that: There are a number of=20 design decisions where it's generally assumed that relay and mining policy= =20 generally match, or at least that mismatches are short lived. When relay policy is more restrictive than what is actually being mined=20 there are at least two serious negative effects. The first is that the latency of block propagation is greatly harmed, a=20 single missed transaction causes a tripling of the per hop transmission=20 delay. If the missed transaction(s) are larger than the TCP window then=20 the increase may be many round trip times. Also if the missed data is=20 large the currently unused prefill mechanism in compact blocks wouldn't=20 help (and would instead likely make things worse as then nodes will get=20 several times the same transaction data from different peers and you cannot= =20 decode the compact block until all the prefill data has been received due= =20 to the message checksum. Delays in block propagation can have a=20 disproportionate effect on mining centralization because they cause larger= =20 miners to have improved profitability over smaller ones. This happens=20 regardless of which party was on which side of the delay, no matter which= =20 side is delayed its the smaller miner's expected profits that are=20 diminisned and the nature of mining competition means that less profitable= =20 miners go bankrupt. This also encourages the establishment of direct miner submission which can= =20 undermine the permissionless nature of bitcoin and in particular again=20 shifts profits towards larger miners because e.g. few would bother=20 connecting to a 1% miner's direct submission interface (if they could even= =20 afford to make one). There are also a number of less significant harms, e.g. more restrictive=20 relay policy makes fee estimation less accurate/complete (though at least= =20 estimation is designed to be fairly robust in that direction).=20 So on this basis I suggest a principle for these sorts of policy: Relay= =20 rules should admit all transactions which are reliably being mined. I think node software should adopt this principal as a general rule. Admitting the transactions is not endorsing them, it's just a recognition= =20 of reality. This policy or equivalent is also the requirement to not=20 suffer from the downsides of relay being more restrictive than mining. If= =20 we imagine that a miner is mining some kind of harmful attack transaction= =20 e.g. a validation DOS attack, then the miner needs to be convinced to stop,= =20 the implementation changed to not have bad performance, and/or consensus=20 rules must be changed ... but relay policy can't address it. By general rule I mean that should something like a miner begin mining e.g.= =20 quadratic hashing bloat legacy txn, or using unused=20 opcode/successcode/version number or whatever by mistake or technical=20 ignorance there is no need to rush off enabling their relay. A general rule= =20 isn't a suicide pact. But if it were the case that transactions misusing a= =20 particular forward compatibility feature were reliably getting mined then= =20 that feature would just no longer be useful for forward compatibility=20 regardless of what relay policy says about it and it would be better to=20 relay them than have the downsides of not doing so. As Antoine Poinsot points out, the existent rule is entirely ineffectual: = =20 Parties current bypass these rules with other transaction forms (such as=20 very harmful address stuffing which is impossible to block) or by direct=20 miner submission, which will continue considering the millions of dollars= =20 miners have received mining transactions with violate the relay rules. =20 Because of this it will not become effectual with time or tweaking. It is= =20 a dead parrot^policy. This is no surprise, since it's a product of=20 Bitcoin's anti-censorship properties that *generally* filtering will not=20 work except on the fringes. As such there isn't practical upside to=20 keeping filtering beyond what miners currently perform.=20 Some Bitcoiners are of the opinion that they still want a knob, I think=20 doing so is a disrespectful placebo[*] but I don't have a strong opinion if= =20 an option remains-- the code is safer and cleaner without some filtering=20 rules that few users would use but that really just a question between=20 software maintainers and users. That said, Bitcoin core has generally not= =20 had knobs to adjust relay policy as distinct from mining policy in large=20 part because of the design assumption that the two need to be the same. =20 But in this case if there were a knob here I think would make more sense=20 for it to control mining policy rather than relay policy, since it would=20 actually have some effect in the mining context (in excluding the txn from= =20 your own blocks) while as a relay only thing it is impotent. =20 [*] It doesn't even conserve their resources meaningfully. They'll still= =20 receive and process the txn, then discard. Then they likely have to fetch= =20 it a second time when it shows up in a block. Although they may save=20 re-transmitting it, on average network wide each transaction is sent once= =20 and received once so the extra transmission for the block should offset the= =20 relay savings. --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn%40googlegroups.com. ------=_Part_28525_854370742.1746167375125 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thursday, April 17, 2025 at 7:09:23=E2=80= =AFPM UTC Antoine Poinsot wrote:

= Since the restrictions on the usage of OP_RETURN outputs encourage harmful=20 practices while being ineffective in deterring unwanted usage, i propose to drop them.

The situation= =20 is even somewhat worse than that:=C2=A0 There are a number of design=20 decisions where it's generally assumed that relay and mining policy=20 generally match, or at least that mismatches are short lived.
When relay policy is more restrictive than what is actually b= eing mined there are at least two serious negative effects.

The first is that the latency of block propagation is greatly harmed,=C2=A0 a= =20 single missed transaction causes a tripling of the per hop transmission=20 delay.=C2=A0 If the missed transaction(s) are larger than the TCP window th= en the increase may be many round trip times.=C2=A0 Also if the missed data i= s=20 large the currently unused prefill mechanism in compact blocks wouldn't=20 help (and would instead likely make things worse as then nodes will get=20 several times the same transaction data from different peers and you=20 cannot decode the compact block until all the prefill data has been=20 received due to the message checksum.=C2=A0 Delays in block propagation can= =20 have a disproportionate effect on mining centralization because they=20 cause larger miners to have improved profitability over smaller ones.=20 This happens regardless of which party was on which side of the delay,=20 no matter which side is delayed its the smaller miner's expected profits that are diminisned and the nature of mining competition means that=20 less profitable miners go bankrupt.

This also=20 encourages the establishment of direct miner submission which can=20 undermine the permissionless nature of bitcoin and in particular again=20 shifts profits towards larger miners because e.g. few would bother=20 connecting to a 1% miner's direct submission interface (if they could=20 even afford to make one).

There are also a=20 number of less significant harms, e.g. more restrictive relay policy=20 makes fee estimation less accurate/complete (though at least estimation=20 is designed to be fairly robust in that direction).

=
So on this basis I suggest a principle for these sorts of policy:=C2=A0=C2=A0= Relay=20 rules should admit all transactions which are reliably being=20 mined.

I think node software should adopt this p= rincipal as a general rule.

Admitting the transa= ctions is not=20 endorsing them, it's just a recognition of reality.=C2=A0 This policy or=20 equivalent is also the requirement to not suffer from the downsides of=20 relay being more restrictive than mining.=C2=A0=C2=A0 If we imagine that a = miner=20 is mining some kind of harmful attack transaction e.g. a validation DOS=20 attack, then the miner needs to be convinced to stop, the implementation changed to not have bad performance, and/or consensus rules must be=20 changed ... but relay policy can't address it.

B= y general rule I mean that should something like a miner begin mining e.g. = quadratic hashing bloat legacy txn, or using unused opcode/successcode/vers= ion number or whatever by mistake or technical ignorance there is no need t= o rush off enabling their relay. A general rule isn't a suicide pact.=C2=A0= But if it were the case that transactions misusing a particular forward co= mpatibility feature were reliably getting mined then that feature would jus= t no longer be useful for forward compatibility regardless of what relay po= licy says about it and it would be better to relay them than have the downs= ides of not doing so.

As Antoine Poinsot points out, the existent rule is entirely ineffectual:=C2= =A0 Parties current bypass these rules with other transaction forms (such=20 as very harmful address stuffing which is impossible to block) or by=20 direct miner submission, which will continue considering the millions of dollars miners have received mining transactions with violate the relay rules.=C2=A0 Because of this it will not become effectual with time or=20 tweaking.=C2=A0 It is a dead parrot^policy.=C2=A0 This is no surprise, sinc= e it's a product of Bitcoin's anti-censorship properties that *generally*=20 filtering will not work except on the fringes.=C2=A0 As such there isn't=20 practical upside to keeping filtering beyond what miners currently=20 perform.

Some Bitcoiners are of the=20 opinion that they still want a knob, I think doing so is a disrespectful placebo[*] but I don't have a strong opinion if an option remains-- the co= de is safer and=20 cleaner without some filtering rules that few users would use but that=20 really just a question between software maintainers and users.=C2=A0 That= =20 said, Bitcoin core has generally not had knobs to adjust relay policy as distinct from mining policy in large part because of the design=20 assumption that the two need to be the same.=C2=A0 But in this case if ther= e=20 were a knob here I think would make more sense for it to control mining=20 policy rather than relay policy, since it would actually have some=20 effect in the mining context (in excluding the txn from your own blocks) wh= ile as a relay only thing it is impotent.
=C2=A0

[*] It doesn't even conserve their resources meaningfully.=C2=A0 They= 'll still receive and process the txn, then discard.=C2=A0 Then they likely= have to fetch it a second time when it shows up in a block.=C2=A0 Although= they may save re-transmitting it, on average network wide each transaction= is sent once and received once so the extra transmission for the block sho= uld offset the relay savings.


<= br />

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn%40googlegroups.com.
------=_Part_28525_854370742.1746167375125-- ------=_Part_28524_2014695618.1746167375125--