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