path: root/62/3336fa0062b595adf3b2bd6fa2cadf6592b007

Delivery-date: Tue, 27 May 2025 10:18:22 -0700
Received: from mail-yw1-f184.google.com ([209.85.128.184])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCO6NFWETEOBBUXH27AQMGQEA7BC3QY@googlegroups.com>)
	id 1uJxwS-0001cZ-PK
	for bitcoindev@gnusha.org; Tue, 27 May 2025 10:18:22 -0700
Received: by mail-yw1-f184.google.com with SMTP id 00721157ae682-70e4e62caa7sf1060347b3.1
        for <bitcoindev@gnusha.org>; Tue, 27 May 2025 10:18:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1748366295; x=1748971095; 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=/VQb9a8UiwBoBizx+zV+vw7ulTiz0yFTTht8JFxyP6k=;
        b=mYeDT7hRmrfqCOoTdKkCYwvvhV0IZEuw+MxSScsixmFu8zRQY8iyZrVYwTxlSnkuII
         Tn4j79k3eEbMY4UtxgJ16EHt+RRG5YUU1SZ5urrLvj/FAEL16v6b0DMPY9wW7XXnQKDs
         +IL619Kwh+8w2CKxOA81+HUq3JgIOPPsjIh0yw6q4wj8pq/k7WozIyttUDR0w4xxwmfe
         yV0TAP8d4RpnbTW1i0LTjKapZ+nfyP9nRfdBoAl+6WHUw9BioTI6qDB8xh9VAqNJagep
         n7XR3WVzRXmCBKDnvX+j5MvAY8Tn7rmTU/nLL6YT/TlE9T/Su/d0siyk/DL4nJcEJuIi
         6dLA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1748366295; x=1748971095; 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=/VQb9a8UiwBoBizx+zV+vw7ulTiz0yFTTht8JFxyP6k=;
        b=L5of/C2EuPqOSZVls7z2KQwIviZGXLk6vOKptnNowxwFfjNTK7qtiJ/AZ78h7Pm/3x
         GbzMB/LO0BrKreHO5YcTKDQ96V8jOI27DdiTLPEDHODSziVWfRqJDQbl/EOB3FWdxpDw
         snr91f2iMyhEkgNwkQZDkeSfk4Jr4zdHJU9LKGIjjLIIiB9TPMo14wvLDVd3IBlIPPKe
         bZhiBIplj4iV9cp/FcbYrOxAZ80Iip9FlohuyNTFTYmDekunXYY2zT0V4ExCdcB5AQxA
         soTzkNMfgM+h0qCuSHxky1z3lpmfARD+JPbZ8A/3Z7iy61FRFddlo71PEx0pbUbxSE/f
         KhSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1748366295; x=1748971095;
        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=/VQb9a8UiwBoBizx+zV+vw7ulTiz0yFTTht8JFxyP6k=;
        b=HDEaqU2Rx/n5sZ6hdoCHYyg4+BCDPgJ39iM53qStbEA3nBOzf4aYOUi7DOHdx3kvEx
         GsH1TEttXla9YW+lc+jEJnZxwJfoBugmJhJpafxypqb7KWNwa5CsYhN5KGiZyUAZ6whg
         ic1dnQMplmHIxv2PTRZmZl31LNBWamlQqsACzxYP6EUH3h9qQqQRZdBs/2l1/BxwtksF
         YB65oLKhwX+jFPaglzbXqZphm1v9jz0InNtQmpCOMsyqMHiBWOsfT3ZFP4zl2oZsBNL6
         K7/jA/pITnxmyCTSizLcaww1i3wDIxzsLXiDT+J4OsEuMl45YLC7iAagmsSXbhZAFCgw
         V4Jg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCVZNvwSpF/MR+YLZgsrBTcRZovKjkaDWofP0NTZlkc9bGqSUYqkZF5JUH2qLz8borncHIUxl8qTzMUm@gnusha.org
X-Gm-Message-State: AOJu0Yxv8ZdWcUyRWgQfWOCarDIwnEZeVlLadQQNbpfTrYN76s2My6iN
	PAPBhARjZBIRzKL7dYmp+7Wzik69q9QDkW4s6+NKlVeHIKvBK9oZaTF7
X-Google-Smtp-Source: AGHT+IGfhOTyI3DntqjuSJkqXi9s+MhjQjWF8wMZRdCvMTCDYiIQgT8yamghZHha9AquXnO1diZb5w==
X-Received: by 2002:a05:6902:20c9:b0:e7d:b4de:578d with SMTP id 3f1490d57ef6-e7dd03e46c7mr1934698276.15.1748366294849;
        Tue, 27 May 2025 10:18:14 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZfyBARV+j0LPvcZfXIaurCMxgv9YsOpVBCBZmW2OoMEKw==
Received: by 2002:a25:dcd3:0:b0:e7d:cd4c:80a6 with SMTP id 3f1490d57ef6-e7dcd4c8206ls705107276.2.-pod-prod-09-us;
 Tue, 27 May 2025 10:18:10 -0700 (PDT)
X-Received: by 2002:a05:690c:3349:b0:708:c18d:e6ac with SMTP id 00721157ae682-70e2d9f421bmr178495297b3.18.1748366290589;
        Tue, 27 May 2025 10:18:10 -0700 (PDT)
Received: by 2002:a05:690c:2d04:b0:70e:2cf8:9db8 with SMTP id 00721157ae682-70e2cf8b6cams7b3;
        Tue, 27 May 2025 09:41:00 -0700 (PDT)
X-Received: by 2002:a05:690c:3349:b0:70e:22ed:e75b with SMTP id 00721157ae682-70e2d9817c2mr158586437b3.8.1748364059028;
        Tue, 27 May 2025 09:40:59 -0700 (PDT)
Date: Tue, 27 May 2025 09:40:58 -0700 (PDT)
From: Jonathan Voss <k98kurz@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <48932bc1-80b2-4d6c-bff0-1d8a2b7f8fc4n@googlegroups.com>
In-Reply-To: <jwBtotbRuz6UW2wLsUSKCSy9Ht29LG4fhn71McZl_ehgzfzZQShTUTwIjWs7n1ZFissKTx74ZZXpXTYXCEMuM0rSi7wnxcFKfZ5h7_kw4Ck=@wuille.net>
References: <a2fde16d-5ddd-47ae-8b8f-6ca313d92b66n@googlegroups.com>
 <jwBtotbRuz6UW2wLsUSKCSy9Ht29LG4fhn71McZl_ehgzfzZQShTUTwIjWs7n1ZFissKTx74ZZXpXTYXCEMuM0rSi7wnxcFKfZ5h7_kw4Ck=@wuille.net>
Subject: Re: [bitcoindev] Proposal to solve the spam war: configurable data
 blob relay policy
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_211964_789710011.1748364058490"
X-Original-Sender: K98kurz@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_211964_789710011.1748364058490
Content-Type: multipart/alternative; 
	boundary="----=_Part_211965_1519049313.1748364058490"

------=_Part_211965_1519049313.1748364058490
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Pieter,

My goal was to design an additional relay service that would allow for a=20
more integrated and seamless use of existing, noncontroversial capabilities=
=20
so that the controversial uses would be obsoleted, thus rendering the=20
current controversy moot. I will address your points below.

On Tuesday, May 27, 2025 at 11:49:00=E2=80=AFAM UTC-4 Pieter Wuille wrote:


Do you mean "and those who *do*=E2=80=8B want to engage in caching ..."? If=
 so, I=20
think this misses the point somewhat. My view isn't that I *want* (or want=
=20
others) to cache/relay non-financial transactions. It's that I believe that=
=20
intentionally instituting or maintaining a relay policy that does not match=
=20
what is making it reliably into blocks anyway is both:

   - largely ineffective (because people can create software with other=20
   policies, or submit directly to miners)
   - harmful on itself (because it slows down block propagation, breaks=20
   various DoS protections in relay by being unable to reason about what is=
=20
   likely to be confirmed, hurts fee estimation, and makes it more profitab=
le=20
   for miners to offer private submission which if widely adopted would hur=
t=20
   the ability for smaller miners to enter the market).


Relay policy is largely effective. If not, then why are there=20
proportionally so few non-standard transactions in blocks? Why is the dust=
=20
limit generally respected if it is an ineffective relay policy? While I=20
agree with the sentiment that inconsistency between relay policy and=20
consensus is not ideal, the reality is that we live in a non-ideal world.=
=20
Relay policies have been historically adopted out of pragmatic concerns.

With regard to fee estimation, is the mempool actually used for this in=20
practice? I have heard conflicting claims on this topic and have not yet=20
dived into the Core source code to figure out this particular issue. The=20
most recent argument I have heard about this is that Core actually uses=20
confirmed transactions from recent blocks to estimate fees rather than the=
=20
mempool; if that is indeed the case, then the fee estimation argument is=20
pointless; if not, then it is a marginal concern -- in practice, fee=20
estimation has always sucked, and the case of it possibly sucking a bit=20
more is not a substantial change in the status quo.

For slowing block propagation, is this a realistic concern? Has anyone done=
=20
any simulation studies or analyzed real world data to determine the impact=
=20
on block propagation of datacarrier-size relay filters? If so, I would=20
appreciate a citation. But if not, then this remains a purely theoretical=
=20
problem.

Moreover, if Core decides to make filters less restrictive and thereby=20
encourage the promulgation of transactions that do not comply with existing=
=20
standardness filters, does that not make the problem worse by increasing=20
the number of previously non-standard transactions that old nodes will have=
=20
to download to verify new blocks? Does this not force node operators to=20
upgrade for the sake of maintaining performance? By enabling the=20
propagation of previously non-standard transactions, logically the result=
=20
will be more of these transactions entering blocks, which just makes the=20
problem worse without full compliance of the whole network in updating=20
relay policy.
=20

While the benefit, even if effective, is minimal: blocks are reliably full,=
=20
and were reliably full long before data-storage schemes became popular,=20
thus nodes are processing the same amount of data anyway. In fact, nodes=20
with policies that diverge from block content will process more data, as to=
=20
them, blocks will contain more unexpected transactions that they still have=
=20
to process anyway.


If a relay service similar to the one I proposed is implemented, then there=
=20
will be no need for this additional data to be downloaded to verify blocks.=
=20
All that nodes will need to download is the transaction containing the=20
OP_RETURN commitment, which they will already have because it fits all=20
existing standardness filters. The additional relay service only needs ~10%=
=20
node adoption to be sufficiently reliable for L2 protocols to utilize, and=
=20
it will not negatively impact the performance of nodes that do not opt-in=
=20
to providing this additional relay service.
=20

Perhaps this was all clear, and your statement was just aiming to be brief,=
=20
but I wanted to make sure you're not misinterpreting the view as *liking*=
=20
non-financial transactions.


Understandable. The primary concerns regarding non-financial transactions=
=20
should be technical rather than aesthetic. On this we agree.
=20

I think you are under the mistaken impression that the disagreement is=20
about what set of transactions should be acceptable on the network, and=20
then crafting a policy that matches that.

To me (and this is just my impression, I don't want to speak for anyone=20
else) the core dispute is about whether a diverging relay policy, even if=
=20
just mildly effective in discouraging use cases, is beneficial or harmful=
=20
to the network. What you're suggesting is instituting even more policy,=20
which is an even larger burden to comply with than what exists today, even=
=20
if it somehow expands what use cases are permitted. To me, that is worse=20
than doing nothing, as it'll even more effectively encourage people to=20
bypass any software implementing such policies, whether that is by the=20
development of even easier and cheaper ways to submit directly to miners,=
=20
or by incentivizing the development or promotion of software that doesn't=
=20
have these policies.


Are you suggesting that all relay policy filters be removed? Or that relay=
=20
policy be abandoned as a concept entirely? What I suggested, if=20
implemented, would not place a significant burden on L2 protocols: place=20
the sha256 of arbitrary data into an OP_RETURN that fits within the=20
standardness policies of ~99% of the network, then send the arbitrary data=
=20
to the nodes that volunteer to relay it. The burden would be the cost of=20
developing and maintaining this additional relay service, but the burden on=
=20
L2 protocol users would not be significantly greater than use of=20
inscriptions or the like. The policy would be tuned so that arbitrary data=
=20
would be cheaper to promulgate via this additional relay service than it=20
would be to include in inscriptions or raw outputs, so there would be no=20
incentive to bypass this system -- it is purely added value for L2 protocol=
=20
users.

-- Jonathan

--=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/=
48932bc1-80b2-4d6c-bff0-1d8a2b7f8fc4n%40googlegroups.com.

------=_Part_211965_1519049313.1748364058490
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Pieter,<div><br /></div><div>My goal was to design an additional relay s=
ervice that would allow for a more integrated and seamless use of existing,=
 noncontroversial capabilities so that the controversial uses would be obso=
leted, thus rendering the current controversy moot. I will address your poi=
nts below.</div><div><br /></div><div><div><div dir=3D"auto">On Tuesday, Ma=
y 27, 2025 at 11:49:00=E2=80=AFAM UTC-4 Pieter Wuille wrote:<br /></div><bl=
ockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204=
, 204, 204); padding-left: 1ex;"><div style=3D"font-family: Arial, sans-ser=
if; font-size: 14px;"><br /></div><div style=3D"font-family: Arial, sans-se=
rif; font-size: 14px;"><div><div>Do you mean "and those who *do*=E2=80=8B w=
ant to engage in caching ..."? If so, I think this misses the point somewha=
t. My view isn't that I *want* (or want others) to cache/relay non-financia=
l transactions. It's that I believe that intentionally instituting or maint=
aining a relay policy that does not match what is making it reliably into b=
locks anyway is both:</div><div><ul style=3D"margin-top: 0px; margin-bottom=
: 0px;"><li style=3D"list-style-type: disc;"><span>largely ineffective (bec=
ause people can create software with other policies, or submit directly to =
miners)</span></li><li style=3D"list-style-type: disc;"><span>harmful on it=
self (because it slows down block propagation, breaks various DoS protectio=
ns in relay by being unable to reason about what is likely to be confirmed,=
 hurts fee estimation, and makes it more profitable for miners to offer pri=
vate submission which if widely adopted would hurt the ability for smaller =
miners to enter the market).</span></li></ul></div></div></div></blockquote=
><div><br /></div><div>Relay policy is largely effective. If not, then why =
are there proportionally so few non-standard transactions in blocks? Why is=
 the dust limit generally respected if it is an ineffective relay policy? W=
hile I agree with the sentiment that inconsistency between relay policy and=
 consensus is not ideal, the reality is that we live in a non-ideal world. =
Relay policies have been historically adopted out of pragmatic concerns.</d=
iv><div><br /></div><div>With regard to fee estimation, is the mempool actu=
ally used for this in practice? I have heard conflicting claims on this top=
ic and have not yet dived into the Core source code to figure out this part=
icular issue. The most recent argument I have heard about this is that Core=
 actually uses confirmed transactions from recent blocks to estimate fees r=
ather than the mempool; if that is indeed the case, then the fee estimation=
 argument is pointless; if not, then it is a marginal concern -- in practic=
e, fee estimation has always sucked, and the case of it possibly sucking a =
bit more is not a substantial change in the status quo.</div><div><br /></d=
iv><div>For slowing block propagation, is this a realistic concern? Has any=
one done any simulation studies or analyzed real world data to determine th=
e impact on block propagation of datacarrier-size relay filters? If so, I w=
ould appreciate a citation. But if not, then this remains a purely theoreti=
cal problem.</div><div><br /></div><div>Moreover, if Core decides to make f=
ilters less restrictive and thereby encourage the promulgation of transacti=
ons that do not comply with existing standardness filters, does that not ma=
ke the problem worse by increasing the number of previously non-standard tr=
ansactions that old nodes will have to download to verify new blocks? Does =
this not force node operators to upgrade for the sake of maintaining perfor=
mance? By enabling the propagation of previously non-standard transactions,=
 logically the result will be more of these transactions entering blocks, w=
hich just makes the problem worse without full compliance of the whole netw=
ork in updating relay policy.</div><div>=C2=A0</div><blockquote style=3D"ma=
rgin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding=
-left: 1ex;"><div style=3D"font-family: Arial, sans-serif; font-size: 14px;=
"><div><div><div></div><div>While the benefit, even if effective, is minima=
l: blocks are reliably full, and were reliably full long before data-storag=
e schemes became popular, thus nodes are processing the same amount of data=
 anyway. In fact, nodes with policies that diverge from block content will =
process more data, as to them, blocks will contain more unexpected transact=
ions that they still have to process anyway.</div></div></div></div></block=
quote><div><br /></div><div>If a relay service similar to the one I propose=
d is implemented, then there will be no need for this additional data to be=
 downloaded to verify blocks. All that nodes will need to download is the t=
ransaction containing the OP_RETURN commitment, which they will already hav=
e because it fits all existing standardness filters. The additional relay s=
ervice only needs ~10% node adoption to be sufficiently reliable for L2 pro=
tocols to utilize, and it will not negatively impact the performance of nod=
es that do not opt-in to providing this additional relay service.</div><div=
>=C2=A0</div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1=
px solid rgb(204, 204, 204); padding-left: 1ex;"><div style=3D"font-family:=
 Arial, sans-serif; font-size: 14px;"><div><div>Perhaps this was all clear,=
 and your statement was just aiming to be brief, but I wanted to make sure =
you're not misinterpreting the view as *liking* non-financial transactions.=
</div></div></div></blockquote><div><br /></div><div>Understandable. The pr=
imary concerns regarding non-financial transactions should be technical rat=
her than aesthetic. On this we agree.</div><div>=C2=A0</div><blockquote sty=
le=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
 padding-left: 1ex;"><div style=3D"font-family: Arial, sans-serif; font-siz=
e: 14px;"><div><div>I think you are under the mistaken impression that the =
disagreement is about what set of transactions should be acceptable on the =
network, and then crafting a policy that matches that.</div></div></div><di=
v style=3D"font-family: Arial, sans-serif; font-size: 14px;"><div><br /></d=
iv><div>To me (and this is just my impression, I don't want to speak for an=
yone else) the core dispute is about whether a diverging relay policy, even=
 if just mildly effective in discouraging use cases, is beneficial or harmf=
ul to the network. What you're suggesting is instituting even more policy, =
which is an even larger burden to comply with than what exists today, even =
if it somehow expands what use cases are permitted. To me, that is worse th=
an doing nothing, as it'll even more effectively encourage people to bypass=
 any software implementing such policies, whether that is by the developmen=
t of even easier and cheaper ways to submit directly to miners, or by incen=
tivizing the development or promotion of software that doesn't have these p=
olicies.</div></div></blockquote><div><br /></div><div>Are you suggesting t=
hat all relay policy filters be removed? Or that relay policy be abandoned =
as a concept entirely? What I suggested, if implemented, would not place a =
significant burden on L2 protocols: place the sha256 of arbitrary data into=
 an OP_RETURN that fits within the standardness policies of ~99% of the net=
work, then send the arbitrary data to the nodes that volunteer to relay it.=
 The burden would be the cost of developing and maintaining this additional=
 relay service, but the burden on L2 protocol users would not be significan=
tly greater than use of inscriptions or the like. The policy would be tuned=
 so that arbitrary data would be cheaper to promulgate via this additional =
relay service than it would be to include in inscriptions or raw outputs, s=
o there would be no incentive to bypass this system -- it is purely added v=
alue for L2 protocol users.</div><div><br /></div><div>-- Jonathan</div></d=
iv></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/48932bc1-80b2-4d6c-bff0-1d8a2b7f8fc4n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/48932bc1-80b2-4d6c-bff0-1d8a2b7f8fc4n%40googlegroups.com</a>.<br />

------=_Part_211965_1519049313.1748364058490--

------=_Part_211964_789710011.1748364058490--