Re: [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy

[Jonathan Voss <k98kurz@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 6912 bytes --]

Hi Pieter,

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

On Tuesday, May 27, 2025 at 11:49:00 AM UTC-4 Pieter Wuille wrote:


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

   - largely ineffective (because people can create software with other 
   policies, or submit directly to miners)
   - harmful on itself (because it slows down block propagation, breaks 
   various DoS protections 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 private 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? While 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 actually used for this in 
practice? I have heard conflicting claims on this topic and have not yet 
dived into the Core source code to figure out this particular issue. The 
most recent argument I have heard about this is that Core actually uses 
confirmed transactions from recent blocks to estimate fees rather 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 practice, 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 anyone done 
any simulation studies or analyzed real world data to determine the impact 
on block propagation of datacarrier-size relay filters? If so, I would 
appreciate a citation. But if not, then this remains a purely theoretical 
problem.

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

While the benefit, even if effective, is minimal: blocks are reliably full, 
and were reliably full long before data-storage 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 transactions that they still have 
to process anyway.


If a relay service similar to the one I proposed 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 transaction containing the 
OP_RETURN commitment, which they will already have because it fits all 
existing standardness filters. The additional relay service only needs ~10% 
node adoption to be sufficiently reliable for L2 protocols to utilize, and 
it will not negatively impact the performance of nodes that do not opt-in 
to providing this additional relay service.
 

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 primary concerns regarding non-financial transactions 
should be technical rather than aesthetic. On this we agree.
 

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 anyone 
else) the core dispute is about whether a diverging relay policy, even if 
just mildly effective in discouraging use cases, is beneficial or harmful 
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 
than doing nothing, as it'll even more effectively encourage people to 
bypass any software implementing such policies, whether that is by the 
development of even easier and cheaper ways to submit directly to miners, 
or by incentivizing the development or promotion of software that doesn't 
have these policies.


Are you suggesting that 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 network, 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 significantly 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, so there would be no 
incentive to bypass this system -- it is purely added value for L2 protocol 
users.

-- Jonathan

-- 
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 email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/48932bc1-80b2-4d6c-bff0-1d8a2b7f8fc4n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 8474 bytes --]