From: Jonathan Voss <k98kurz@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Proposal to solve the spam war: configurable data blob relay policy
Date: Tue, 27 May 2025 09:40:58 -0700 (PDT) [thread overview]
Message-ID: <48932bc1-80b2-4d6c-bff0-1d8a2b7f8fc4n@googlegroups.com> (raw)
In-Reply-To: <jwBtotbRuz6UW2wLsUSKCSy9Ht29LG4fhn71McZl_ehgzfzZQShTUTwIjWs7n1ZFissKTx74ZZXpXTYXCEMuM0rSi7wnxcFKfZ5h7_kw4Ck=@wuille.net>
[-- 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 --]
next prev parent reply other threads:[~2025-05-27 17:18 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-24 21:07 Jonathan Voss
2025-05-27 14:16 ` Pieter Wuille
2025-05-27 16:40 ` Jonathan Voss [this message]
2025-05-27 16:02 ` 'Russell O'Connor' via Bitcoin Development Mailing List
2025-05-27 16:51 ` Jonathan Voss
2025-05-27 23:10 ` Dave Scotese
2025-05-28 13:16 ` Greg Sanders
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48932bc1-80b2-4d6c-bff0-1d8a2b7f8fc4n@googlegroups.com \
--to=k98kurz@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox