From: Pieter Wuille <bitcoin-dev@wuille•net>
To: Luke Dashjr <luke@dashjr•org>
Cc: Sjors Provoost <sjors@sprovoost•nl>, bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
Date: Sat, 26 Apr 2025 12:48:00 +0000 [thread overview]
Message-ID: <QMywWcEgJgWmiQzASR17Dt42oLGgG-t3bkf0vzGemDVNVnvVaD64eM34nOQHlBLv8nDmeBEyTXvBUkM2hZEfjwMTrzzoLl1_62MYPz8ZThs=@wuille.net> (raw)
In-Reply-To: <d18b4149-5523-44bd-8332-2b7962f4b674@dashjr.org>
On Saturday, April 26th, 2025 at 7:45 AM, Luke Dashjr <luke@dashjr•org> wrote:
> That's nonsense. They were and continue to be very effective, even with
> only a small amount of adoption. Further, mining centralization and
Standardness rules have definitely been effective in the past, if we go far enough back in time. But back then:
* There were far less financial incentives to bypass them. Standardness adds inconvenience to people developing infrastructure on top, which can nudge in another direction. But I don't see how million-dollar (or more) business incentives would be thwarted by the need to communicate with miners directly (see below). These incentives will only increase as the subsidy dwindles.
* There was far more reason for rules of this kind; the network was small and far less valuable, and there were significant concerns about increased node operation cost with a quickly-growing blockchain. With blocks consistently full for most of the time for years now, even at times without so-called "spam", that concern just does not exist; nodes will be processing the same amount of transaction data anyway. I think I share Luke's feelings around non-financially-relevant transactions on-chain, but given sufficient demand for block space anyway, there just is no need to discriminate.
> pools denying miners options has been the biggest barrier to that
> adoption. There is no significant financial impact either, that's just
> FUD; miners using the fixed and improved spam filters have in fact
> earned significantly more than miners using Core.
I am doubtful of this claim, and would like to see evidence of it.
> It would be a pain, but it is definitely viable. Thankfully, policy
> works just fine for spam filtration, and can be adapted much quicker.
Nobody is required to adopt policy, and I think you're burying your head in the sand if you believe even in a world with more decentralized hashpower, miners/hashers would voluntarily choose to disregard transactions that pay a significant fee, if the potential gains from accepting them exceed the cost of building infrastructure to bypass whatever policy exists.
Bitcoin users do have a means to deny usage of the chain to truly damaging use: consensus changes. Those are not optional, apply to everyone equally, do not create incentives for bypass, and - and I believe that is a good thing - can only be adopted with very wide agreement.
> > b) centralisation
>
> No, this is more FUD.
The **entire** reason why Bitcoin uses PoW, as opposed to using a traditional consensus system with a federation of block-builders, is to avoid censorship. If anyone dislikes the choices current miners make in what transactions they accept, they can - without asking anyone for permission - join the set of miners, and earn a proportional piece of the pie. While it is the case that today mining power is quite concentrated in a number of businesses, the set of such businesses can, and has, changed over time. This is a very valuable property.
Part of the puzzle to make that permissionlessness of mining work is access to fee-paying transactions from the public. If sufficient economic demand exist for transactions that the public network denies, miners and creators of such transaction will develop transaction rails that bypass that network.
If it comes to a point where that economic demand is so high that miners need to rely on private transaction rails to realistically compete, I feel we'd be giving up on one of the most valuable properties the network has. I realize this is a slipstreamery-slope argument, but it is already happening, and once the rails are ubiquitous, it will be very hard to go back to a public network.
---
Because of all these reasons, Concept ACK on relaxing the OP_RETURN limits, including removing them entirely. I have been a strong proponent of these limits in the past, and I'm not happy with seeing the demand for those transactions. But I also recognize the reality that that demand exists, and the alternative of pushing that demand to bypass the public network is far more damaging.
I will add that I am not in favor of relaxing many other standardness rules in Bitcoin Core, such as transaction sizes and other resource limitations. These have significant impact on the public's ability to verify and relay transactions, and reason about incentive compatibility while doing so. Significant and sustained economic demand for such transactions may at some point too mean the policy needs to be revised to avoid an even worse outcome, but I'm hopeful that is not the case. However, these arguments do not apply to OP_RETURN limits, which don't serve an objective harm reduction beyond a subjective "that isn't what you should be using the chain for".
--
Pieter
--
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/QMywWcEgJgWmiQzASR17Dt42oLGgG-t3bkf0vzGemDVNVnvVaD64eM34nOQHlBLv8nDmeBEyTXvBUkM2hZEfjwMTrzzoLl1_62MYPz8ZThs%3D%40wuille.net.
prev parent reply other threads:[~2025-04-26 12:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 18:52 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 12:03 ` Sjors Provoost
2025-04-18 12:54 ` Greg Sanders
2025-04-18 13:06 ` Vojtěch Strnad
2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 21:34 ` Antoine Riard
2025-04-20 8:43 ` Peter Todd
2025-04-26 9:50 ` Luke Dashjr
2025-04-26 10:53 ` Sjors Provoost
2025-04-26 11:35 ` Luke Dashjr
2025-04-26 11:45 ` Sjors Provoost
2025-04-26 12:48 ` Pieter Wuille [this message]
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='QMywWcEgJgWmiQzASR17Dt42oLGgG-t3bkf0vzGemDVNVnvVaD64eM34nOQHlBLv8nDmeBEyTXvBUkM2hZEfjwMTrzzoLl1_62MYPz8ZThs=@wuille.net' \
--to=bitcoin-dev@wuille$(echo .)net \
--cc=bitcoindev@googlegroups.com \
--cc=luke@dashjr$(echo .)org \
--cc=sjors@sprovoost$(echo .)nl \
/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