pull down to refresh
@Murch
stacking since: #127838
0 sats \ 0 replies \ @Murch 10 May \ parent \ on: JPEGS or no JPEGS... Bitcoin dies without Fee Pressure. THAT is the Truth bitcoin
Right, we can’t force them, but we can make OP_RETURN data more attractive than writing to payment outputs.
It seems to me that you could have done the same reveal trick with P2SH, but you would have been limited to 520 bytes, because the redeem script has to fit in a single push and 520 bytes is the maximum push size.
If you want to write a BIP, please check out BIP 2 which provides guidelines for would-be BIP authors.
Part of the legacy wallet removal project was that Ava wrote a new minimal read-only implementation of BDB that has all the parts we need for being able to read legacy wallets indefinitely. The wallet migration tool will be part of all future releases of Bitcoin Core.
If the profitability goes down too much, there may be a build-up of unused hardware that could potentially be used to attack the chain more profitably than to contribute to writing new blocks.
Might be more of a ELI12, but here goes:
There are people that like to write pictures into the Bitcoin blockchain. Some Bitcoiners don’t want pictures in the blockchain. They want that only payment transactions can be written to the blockchain. The Knots marketing team has been telling them that running Knots makes it harder to put pictures in the blockchain, because Knots does not forward unconfirmed transactions with pictures.
In the past two years, picture-lovers have spent hundreds of millions of dollars to put pictures into the blockchain. Bitcoin Core contributors also don’t like picture transactions, but they think that just not forwarding transactions will not slow down picture transactions. Instead it will make picture enthusiasts build tools to give picture transactions directly to miners. The Bitcoin Core contributors worry that if picture-lovers give their transactions directly to miners, this will a) slow down block propagation, b) disimprove fee estimation, and c) disproportionally benefit the largest miners. Picture transactions can only be effectively forbidden by new consensus rules that reduce the programmability of Bitcoin transactions, but Bitcoin Core contributors think that working on that would take too much time and effort, and that neutering Bitcoin’s scripting system to prevent picture transactions is too high of a price. Many Bitcoin Core contributors think that picture transactions will be too expensive in the long run and will be naturally priced out by more valuable payment transactions. They say that is unnecessary to make the network work worse or to reduce Bitcoin’s programmability to fight against picture transactions. This makes the people angry that want Bitcoin to only be used for payment transactions. They want that Bitcoin Core contributors do everything they can to fight picture transactions.
Last week someone pointed out that someone intends to write data into payment outputs. This is especially bad, because unspendable payment outputs are stored in the UTXO set and have to be kept by all full nodes forever. They bring up the idea to allow bigger OP_RETURN outputs, because OP_RETURN outputs cost a little less than writing to payment outputs and are not stored in the UTXO set. They note that the picture writing happens mostly in witness data which is already cheaper, and therefore probably only any data that would be written in payment outputs would instead be written to OP_RETURN outputs. A participant of this conversation opens a pull request to Bitcoin Core to propose dropping the OP_RETURN limit and removing the configuration option to set a limit.
The Knots marketing team uses this proposed code change as an opportunity to stoke fear by saying that Bitcoin Core has already decided to do this, and that this code change would bloat the blockchain, the UTXO set, the mempool, make validation slower, invite even more picture transactions, and spell the end for payment transactions. They also admonish that Bitcoin Core is silencing people who don’t like pictures by dropping the configuration option. However, it is just a proposal that is being discussed at this point. Further, OP_RETURNs appears in output scripts, and output scripts are not subject to the witness discount. So, OP_RETURN data pays the full price for blockspace, more OP_RETURN data results in smaller blocks, and OP_RETURNs are cheap to validate. Before any Bitcoin Core contributors realize what is happening, picture-haters start demonstrating in Bitcoin Core’s workplace. When some of the demonstrators get carried away, security asks them to leave. The Knots marketing team decries censorship to further fan the flames. Meanwhile, many Bitcoin Core contributors think that mining centralization is an important issue and that writing to the UTXO set is much worse than potentially a few additional OP_RETURN outputs, and they are divided on whether they configuration option should be kept or dropped. Another proposal is created that only changes the OP_RETURN limit but keeps the configuration option. A bunch of Bitcoin Core contributors then spends a week to explain the broader picture and their perspective instead of working on the things they were going to do otherwise.
Might be better to talk about this when the content is known rather than talking about the announcement of an announcement.
It seems to me that it is more of a continuation of the disconnect caused by the project’s approach to and communication around Inscriptions than about the current issue at hand.
A lot of Bitcoiners have strong emotions about Bitcoin’s sole use for payments and feel that their concerns about data transaction were not sufficiently considered by Bitcoin Core contributors in the past couple years. Bitcoin Core contributors need to do a better job of participating in the community conversation to regain some of the lost trust, although the disagreement seems somewhat inevitable due to the gap between idealistic stances and the trade-offs that present themselves in practice.
Maybe this got lost, but other mempool policies also remain in place. Transactions are limited to 400,000 weight units (100,000 vB).
Beyond that, consensus rules still limit blocks to 4,000,000 weight, and OP_RETURN bytes weigh 4 weight.
I think all three of these are already covered here:
Why is the 80-byte OP_RETURN limit being removed, and what are the main risks and benefits of this change?
Will node operators still be able to set their own OP_RETURN size limits, or is the configuration option also being removed?
How does removing the OP_RETURN limit impact UTXO set bloat and network health compared to current workarounds?
Bitcoin Improvement Proposals are specifications that describe a new concept, protocol feature, or standard that its authors recommend for adoption to the Bitcoin community. The topic must be relevant to multiple software projects.
Usually, mempool policy defaults are selected by projects without coordination, unless they are picked coordinate interaction with other projects (see e.g. BIP 431). There are multiple node implementations that differ in mempool policy in a number of different ways. As such, a mempool policy change in Bitcoin Core might be discussed on the mailing list, but lower impact changes might even just be decided at the project level.
BTW, some BIP Editors have contended that mempool policy is generally not BIPable.
I don’t think there was any urgency attached to this pull request until it blew up on social media. The next Bitcoin Core release is planned for October. Whether the change were to get merged in May or in August, it wouldn’t come out before October.
The sense of urgency was generated by opponents claiming that immediate action was necessary to save Bitcoin.
If the loosening of the OP_RETURN limit was your main concern, that concern does not apply Bitcoin Core 29.0. I’m not aware of any other changes that are considered controversial, but I don’t know what criteria you have, so you may want to peruse the release notes yourself: https://bitcoincore.org/en/releases/29.0/
Bitcoin Core 29.0 was released before the debate about OP_RETURN started. The change discussed in the pull request would be released with Bitcoin Core 30.0 in October at the earliest if it gets merged.
The point is that direct submission and private relay result in a subset of the miners building blocks from a bigger pool of transactions, because they have access to transactions other miners don't know about. Not that the out of band fees are too high.
That means if they are malicious we can't do anything at the protocol level, regardless of whether OP_return is there or not, correct?
The only effective recourse would be a protocol change that amends all output types such that they incorporate a proof that the output scripts are spendable when they are created. Even then, data could be embedded via other transaction fields or grinding pubkeys and signatures.
This is something that is confusing to me, because if that is the case, then no matter what happens with this debate, Bitcoin is just a sitting duck waiting to be defenestrated by someone with the right backing and know-how.
Pretty much. That’s why many people were upset about Stamps specifically. Stamps were unabashedly malicious by needlessly polluting the UTXO set. (They were even explicitly marketed as "unprunable".)
And if there is something we can do against a bad actor, then why not do it now, instead of rolling the red carpet and hoping they will behave themselves?
As explained, there isn’t much that can be done, except social pressure or hard forks with really horrible trade-offs. OP_RETURN is a mitigation in the sense that it would have 5–10 bytes less overhead for a small data payload and more for large data payload than fake pubkeys. So, it’s not only a request to be a good citizen, but also provides a (small) financial incentive to be a good citizen by being cheaper.
By the way, the long form replies are very helpful. Thank you for taking the time.
You’re welcome. I’m glad that people are reading this and find it useful.
You are welcome, thank you for taking the time to read my comments.
- Writing data to a taproot leaf script. Lifting the OP_RETURN limit will not provide an attractive alternative for people embedding data, for any data above 143 bytes. So not effective against most arbitrary data.
- Data in the output script using the OP_RETURN op code. Lifting the limit seeks to encourage more data to be embedded using OP_RETURNs, as the current limit may prevent some data from being propagated around the network as it becomes non standard. (But can be worked around by going to a miner out of band)
I would perhaps quibble with "seeks to encourage", but overall we agree.
- Embedding data using fake public keys or hashes. Does raising the OP_RETURN limit offer an incentive for this kind of embedded data? Does it become cheaper using OP_RETURN or not?
Yes, a data payload embedded per OP_RETURN would be cheaper than fake public keys or pubkey hashes. I calculate that it would save at least 5–10 bytes of overhead for a small data payload, and much more for larger data payloads.
And one final question, why is this company Citrea being cited so much in this PR and discussion? I see Core Devs linking to their Whitepaper in the PR and I wonder why a single company's use case and requirements are being considered to heavily in this discussion. Shouldn't that be a non factor for a Bitcoin Core PR?
My read is that Citrea provides a concrete example of detrimental behavior that could be mitigated by raising the OP_RETURN limit. Since there is a concrete description of their scheme it makes an easy to communicate example.