path: root/72/2a2a3a6d18f04acbfe861abe83623c6b69a7dc

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 <bitcoindev+bncBCJNLJPWXAIBBB6V2HAAMGQELJ4KF4A@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <gmaxwell@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com>
In-Reply-To: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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

<br /><div><div dir=3D"auto">On Thursday, April 17, 2025 at 7:09:23=E2=80=
=AFPM UTC Antoine Poinsot wrote:<br /></div><blockquote style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1=
ex;"><br /><div style=3D"font-family: Arial, sans-serif; font-size: 14px;">=
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. <br /></div></blockquote><div><br /></div><div>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.</div><div><br=
 /></div><div>When relay policy is more restrictive than what is actually b=
eing mined there are at least two serious negative effects.</div><div><br /=
></div><div>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.</div><div><br /></div><div>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).</div><div><br /></div><div>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). <br /></div><div><br />=
</div><div>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.</div><div><br /></div><div>I think node software should adopt this p=
rincipal as a general rule.</div><div><br /></div><div>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.</div><div><br /></div><div>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.</div><div><br /></div><div>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. <br /></div><div><br /></div><div>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.</div><div>=C2=A0</div></div><br /=
><div>[*] 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.</div><div><br /></div><div><br /></div><div><=
br /></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn%40googlegroups.com</a>.<br />

------=_Part_28525_854370742.1746167375125--

------=_Part_28524_2014695618.1746167375125--