From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 02 May 2025 12:11:28 -0700 Received: from mail-yb1-f184.google.com ([209.85.219.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uAvnC-0001Ji-SH for bitcoindev@gnusha.org; Fri, 02 May 2025 12:11:28 -0700 Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e5b0f2778d6sf3523213276.3 for ; Fri, 02 May 2025 12:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1746213081; x=1746817881; 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=RdxH6pSXJG4Cm1QFVloyhXecShnpqNfHDn+KHEZ27zw=; b=iaSsrFfNZkqrjM8+NFhZx+pCFAGU4skax3rfK3fLp5AcxBGAV5VZn79ceSKURCijLk 4q1QrfHzUfj0tf4r8fnMMLf0FiJOdoUW+9pF+kD5cuPy5zb5vUqZhiiP5d7QrlIL+Cq8 TbNyBZ2IhhyZPknjKPJRqZqqT9XZBjQ+EsJ2fZRfC6Ay8IP8BzVDHsDCu12RMcEyG8iP 4SxwFzhg+2zMLShBLlZsj4ghiMN2qx2JzJHjyehaRrGA9sC8QvQaP/vRH4aV4ajE7Cqr 1IAc0hiet/JZIgxGKjQZKSkUFtnymMurl4VlNocQG4uGhuNX9MyNuikG8AnQzvJUQjlN 4iuA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746213081; x=1746817881; 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=RdxH6pSXJG4Cm1QFVloyhXecShnpqNfHDn+KHEZ27zw=; b=WbsLYgvwSojc3wITI8A9tPFNNMD3vqd6f9eRcR8hBVii2cOsjVfAoqWGYu9jsm7MGE k9rF2HmCVLHNnMyC9L21acEbmpkfBVVBWmuPsDPBKsZ2bBbV6GPETR3KMjdI1ssU3MEW T7greN0sbqpmkd/I4kkViwz+cR7LncG0H/w93oMKnrXGu8ztCN2ryJVisQEe78vF9Q43 vQrYpb2ez1ode3M4ARbKKefzusAc+7oBd+bqu4e2q2k4yAoIJkrvtXBkr77qJnVLsCyI q23mOX0Pq/yXV78wbd8S7k1u1ven4Gi1gkc44IkBGjdY7mzIAnI3sJdgviTxBGXLgPKE pocw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746213081; x=1746817881; 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=RdxH6pSXJG4Cm1QFVloyhXecShnpqNfHDn+KHEZ27zw=; b=hABfEnGioeNTAm+4Krfw4uxrgEFSo2wPN82w9lI240cL9WXjvpFc3PSJ/ys+qa+l88 mC/2c2lSN7SnK5Bd3tlsf7zQinQDKPrgq/XmKFZiZAf2vUBW7raJ7teo7fHXglmCpdTH LN5yBoYoeAGomjYHL/Fu466x5j+73MBg3GfqUekyVG1gpAw31Q1lJ0r45gubz/SOBauI IYLtsaW0awr6Qw8toRRZP9OUxbJVQ2bTXFY2xVoD25ewz4XY9EKWsxGaaoE8/PLDkSAB fuMUzx45RYFmkoq8kfpKIwu3qCC4mqecf30uxUuhCQaLg4kgBPOfTi9d1qCP7rjIyHOP 553Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCX3CtHHAhljTNXqlNq4GPH33NuD+GbCEI+LAcnvGGBDMy+lpf2Jx8tlJCXWw2aimBJNxSC+ntEnqxWq@gnusha.org X-Gm-Message-State: AOJu0YzP7tWZOp1MB9xmSJeV/kIR/thirLYi2svAaO0kNxDA5s4bDUlj Z/g5P6Du32QoF07rZK62kt3bldSakaMqF4yI0TcZWm4V3pOTuV3m X-Google-Smtp-Source: AGHT+IHks0BBLe/vB5miJm+M0cu0oiLDrHKPAPBQez/EHSEyCENaNfkjtMBSVcVIzcl6x0uWutQvfg== X-Received: by 2002:a05:6902:2484:b0:e73:3239:9328 with SMTP id 3f1490d57ef6-e756556fb4bmr5320313276.18.1746213080965; Fri, 02 May 2025 12:11:20 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBF3gyi3OQrxXVNfLrVKDbe43Ep4V8cy1UK4kTwTZJMRUg== Received: by 2002:a25:ceca:0:b0:e5b:3877:6d59 with SMTP id 3f1490d57ef6-e74d9b7ccb1ls739072276.0.-pod-prod-05-us; Fri, 02 May 2025 12:11:17 -0700 (PDT) X-Received: by 2002:a05:690c:c1e:b0:707:48a7:ea74 with SMTP id 00721157ae682-708ced71441mr61446137b3.22.1746213077210; Fri, 02 May 2025 12:11:17 -0700 (PDT) Received: by 2002:a81:f801:0:b0:6ef:590d:3213 with SMTP id 00721157ae682-708cfb0b4cems7b3; Fri, 2 May 2025 12:04:15 -0700 (PDT) X-Received: by 2002:a05:690c:9c09:b0:6f5:2793:2897 with SMTP id 00721157ae682-708cede52a1mr63044547b3.30.1746212653775; Fri, 02 May 2025 12:04:13 -0700 (PDT) Date: Fri, 2 May 2025 12:04:13 -0700 (PDT) From: /dev /fd0 To: Bitcoin Development Mailing List Message-Id: <47454755-7c6c-458b-9545-8c8657b640f1n@googlegroups.com> In-Reply-To: <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com> References: <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com> Subject: [bitcoindev] Re: Relax OP_RETURN standardness restrictions MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_104504_590750689.1746212653410" X-Original-Sender: alicexbtong@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_104504_590750689.1746212653410 Content-Type: multipart/alternative; boundary="----=_Part_104505_1689129783.1746212653410" ------=_Part_104505_1689129783.1746212653410 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg, > 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--=20 > the code is safer and cleaner without some filtering rules that few users= =20 would use but that really just a question between software maintainers and= =20 users. > That said, Bitcoin core has generally not had knobs to adjust relay=20 policy as distinct from mining policy in large part because of the design= =20 assumption that the > two need to be the same. But in this case if there were a knob here I=20 think would make more sense for it to control mining policy rather than=20 relay policy, > since it would actually have some effect in the mining context (in=20 excluding the txn from your own blocks) while as a relay only thing it is= =20 impotent. Config `mempoolfullrbf` was added in July 2022:=20 https://github.com/bitcoin/bitcoin/pull/25353 It was made default in August 2024:=20 https://github.com/bitcoin/bitcoin/pull/30493 Option was removed in November 2024:=20 https://github.com/bitcoin/bitcoin/pull/30592 `datacarrier` and `datacarriersize` already exist, so why is it a big deal= =20 to remove them after a few months of monitoring the usage with stats?=20 /dev/fd0 floppy disk guy On Friday, May 2, 2025 at 12:17:40=E2=80=AFPM UTC+5:30 Greg Maxwell wrote: > On Thursday, April 17, 2025 at 7:09:23=E2=80=AFPM UTC Antoine Poinsot wro= te: > > > Since the restrictions on the usage of OP_RETURN outputs encourage harmfu= l=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 polic= y=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 cann= ot=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 large= r=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 profitabl= e=20 > miners go bankrupt. > > This also encourages the establishment of direct miner submission which= =20 > can undermine the permissionless nature of bitcoin and in particular agai= n=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 eve= n=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 sto= p,=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=20 > e.g. 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 ru= le=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 i= s=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 no= t=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 fro= m=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 fetc= h=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 t= he=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/= 47454755-7c6c-458b-9545-8c8657b640f1n%40googlegroups.com. ------=_Part_104505_1689129783.1746212653410 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Greg,

>=C2=A0Some Bitcoiners are of the 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--=C2=A0
&= gt; the code is safer and cleaner without some filtering rules that few use= rs would use but that really just a question between software maintainers a= nd users.
> That said, Bitcoin core has generally not had knob= s to adjust relay policy as distinct from mining policy in large part becau= se of the design assumption that the
> two need to be the same= . =C2=A0But in this case if there were a knob here I think would make more = sense for it to control mining policy rather than relay policy,
&= gt; since it would actually have some effect in the mining context (in excl= uding the txn from your own blocks) while as a relay only thing it is impot= ent.

Config `mempoolfullrbf` was added in July 2022:=C2=A0https://github.com/bitc= oin/bitcoin/pull/25353
It was made default in August 2024:=C2=A0https://github.com/= bitcoin/bitcoin/pull/30493
Option was removed in November 2024:=C2= =A0https://github= .com/bitcoin/bitcoin/pull/30592

`datacarrier` and `datacarri= ersize` already exist, so why is it a big deal to remove them after a few m= onths of monitoring the usage with stats?=C2=A0

= /dev/fd0
floppy disk guy

On Friday, May 2, 2025 at 12:17:= 40=E2=80=AFPM UTC+5:30 Greg Maxwell wrote:
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 si= tuation=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 bei= ng 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 profit= s 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 pri= ncipal as a general rule.

Admitting the transactio= ns is not=20 endorsing them, it's just a recognition of reality.=C2=A0 This policy o= r=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.

By general rule I mean that should something like a miner begin mining e.g= . quadratic hashing bloat legacy txn, or using unused opcode/successcode/ve= rsion number or whatever by mistake or technical ignorance there is no need= to 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 forw= ard compatibility feature were reliably getting mined then that feature wou= ld just no longer be useful for forward compatibility regardless of what re= lay policy says about it and it would be better to relay them than have the= downsides 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-- th= e code 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

<= div>[*] It doesn't even conserve their resources meaningfully.=C2=A0 Th= ey'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 Al= though they may save re-transmitting it, on average network wide each trans= action is sent once and received once so the extra transmission for the blo= ck should offset the relay savings.



--
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/47454755-7c6c-458b-9545-8c8657b640f1n%40googlegroups.com.
------=_Part_104505_1689129783.1746212653410-- ------=_Part_104504_590750689.1746212653410--