From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <48932bc1-80b2-4d6c-bff0-1d8a2b7f8fc4n@googlegroups.com> In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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,

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.

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

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:
  • largely ineffective (bec= ause people can create software with other policies, or submit directly to = miners)
  • 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).

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.

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.

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.

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.
=C2=A0
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.=

Understandable. The pr= imary concerns regarding non-financial transactions should be technical rat= her than aesthetic. On this we agree.
=C2=A0
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.

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.

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.

-- Jonathan

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