Quick questions about OP_RETURN? Quick answers here. \ stacker news ~bitcoin

pull down to refresh

Quick questions about OP_RETURN? Quick answers here.

22k sats \ 96 comments \ @tidwell 20h bitcoin

zaps forwarded to @Murch (51%)

There has been a lot of debate about a recent discussion on the mailing list and a pull request on the Bitcoin Core repository. The main two points are about whether a mempool policy regarding OP_RETURN outputs should be changed, and whether there should be a configuration option for node operators to set their own limit. There has been some controversy about the background and context of these topics and people are looking for more information. Please ask short (preferably one sentence) questions as top comments in this topic. @Murch, and maybe others, will try to answer them in a couple sentences. @Murch and myself have collected a few questions that we have seen being asked to start us off, but please add more as you see fit.

view all related items

1110 sats \ 3 replies \ @tidwell OP 19h

Users should be given clear configurable options to decide what's in their mempool, why were these options taken away?

1568 sats \ 1 reply \ @Murch fwd 18h

Generally, a configuration option should be provided when one can provide recommendations when the configuration option should be used and how it should be adjusted. Historically, it looks like the vast majority of Bitcoin Core nodes use the default configuration. When at least about 10% of nodes accept a transaction, it propagates somewhat reliably to all nodes in the network that accept them.

This means that if the default configuration for the OP_RETURN limit were raised or removed altogether, such transactions would soon after the release reliably propagate and, perhaps a little later, also get mined by a larger proportion of the block authors. Node operators setting a lower limit would do so at their detriment: they would download the transactions after an announcement from their peers, reject adding it to their mempool, then download the same transactions again when a block includes them, incurring increased bandwidth and extra latency on the updating to the latest chain tip.

Some proponents of the increased limit argue that the configuration option should not have been added in the first place, as it is ineffective to locally configure a different limit, and that the configuration option is even less useful after dropping the limit. Other contributors argue that setting a lower limit only harms the node operator, and removing the configuration option takes away control needlessly.

100 sats \ 0 replies \ @hgw39 4h

With all due respect, I don't think you've answered the question. Your make valid points for the justification of the increase in the limit and explain that individual nodes may be harming themselves, default settings are the norm and the transactions will be propagated anyway. You've even pointed out that the ability to configure this setting was debated anyway and some consider that it shouldn't have been added. But the question asks something different, something I am wondering also. As a sovereign node runner in an open permissionless network, why does this PR propose to remove the ability for me to configure the mempool settings on my own node? If I make a decision that harms myself and doesn't make any difference to the propagation of transactions, isn't that for me to decide and bear the consequences of? It's like re-using addresses, commonly accepted as poor for privacy but there is no rule in the protocol that permits it. It's up to me to understand and accept the consequences.

42 sats \ 0 replies \ @TheCharlatan 17h

@Murch has provided an excellent answer, but I would also like to mention that there were also some technical arguments in favour of retaining the option. It could allow an ideological miner with a stratumv2 or datum template provider, or ideological mining pool to exclude these OP_RETURN transactions from their block template. This has sparked a conversation around potentially separating transaction relay and mining policy, or even retaining the option for this reason. Some might argue even further that nodes adopting a stricter OP_RETURN size limit in their policy could be more likely to relay lower fee transactions to these miners or pools. However, I don't think this is a good idea for all the reasons Murch has laid out. The issue was opened here: https://github.com/bitcoin/bitcoin/issues/32401.

A similar option also exists for denying the usage of bare multisig (p2ms) outputs (-permitbaremultisig). These are a type of output intended for multisig, but widely used for data embedding through the counterparty protocol and stamps. It is currently default off. Making it default on, or removing it, have led to similar controversies in the past. My expectation is this will be revisited again too depending on the outcome of the current controversy.

110 sats \ 7 replies \ @tidwell OP 19h

How would someone get around the standardness policy currently for OP_RETURN size?

110 sats \ 6 replies \ @Murch fwd 19h

Some Bitcoin node implementations such as Libre Relay have less strict mempool policies and relay transactions that would be considered non-standard by Bitcoin Core. Some mining pools use similar mempool policies and additionally accept direct submissions out-of-band.

As transactions with multiple OP_RETURN outputs or larger OP_RETURN outputs are permitted by the consensus rules, blocks that include these non-standard transactions are accepted by all nodes.

97 sats \ 5 replies \ @petertodd 17h

Also important to mention: Libre Relay automatically peers with other Libre Relay nodes. So even with only a small minority of Libre Relay nodes, transactions still propagate reliably.

42 sats \ 4 replies \ @028559d218 17h

So in other words... attempts to 'filter' transactions successfully by running a client with 'stricter' mempool policy than core... is pretty much hopeless? ????

31 sats \ 2 replies \ @Murch fwd 16h

It takes only about 10% of nodes to somewhat reliably propagate a transaction. Even fewer are enough if they preferentially peer like Libre Relay does (TIL!). So, yes, it’s not effective.

0 sats \ 1 reply \ @petertodd 13h

You learned that today? Sheesh.

My first full-rbf fork of Bitcoin Core with preferential peering was released in 2014.

view all 1 replies

31 sats \ 0 replies \ @petertodd 17h

Censorship, stifling information, is always more difficult than spreading it.

110 sats \ 7 replies \ @tidwell OP 19h

A similar PR was proposed by Peter Todd 2 years ago, why was it rejected then? What has changed since then, why would this get approved now?

152 sats \ 6 replies \ @petertodd 17h

For the record, this pull-req wasn't my idea. I was asked to open it by an active Core dev because entities like Citrea are using unprunable outputs instead of OP_Return, due to the size limits. And yes, that's the thing that has changed since.

21 sats \ 0 replies \ @484289fb91 11h freebie

Why wouldn't the core dev open this themself?

84 sats \ 3 replies \ @028559d218 16h

With all due respect, and I mean this totally neutrally...

Is there any way to get Citrea to just stop? Like hey, 'cut it out'?

Some of the criticisms I've heard are specifically that one company wants to make use of larger op_return data fields... so why change mempool policy for one company specifically? What if another company in the future wants to do something else, even if in the spirit of harm reduction, should we change mempool policy just for a company to play defi?

Another question: how many unprunable outputs are we talking about from Citrea? Hundreds? Thousands? Tens of thousands? Is this something really core to their business model? Is there any other way of them doing what they want to do, without requiring such a change? How polluting would they (or the others to follow them) really be for the network?

Finally, since LibreRelay works with only a limited number of nodes in the network available... why don't they just use LibreRelay? That way they could have larger op_returns without necessitating unprunable outputs. THANK YOU

102 sats \ 1 reply \ @petertodd 16h

Is there any way to get Citrea to just stop? Like hey, 'cut it out'?

In this particular case, definitely not. Even with the "prove your bytes aren't arbitrary data" soft fork proposal they're doing something valuable enough to make grinding bytes feasible.

why don't they just use LibreRelay?

Because this type of Citrea transaction is time sensitive. Only two major mining pools mine oversized OP_Returns right now. That means there's a decent chance this type of Citrea transaction – a tx that responds to fraud – would fail to be mined.

0 sats \ 0 replies \ @tlindi 16m

they're doing something valuable enough to make grinding bytes feasible.

To whom it is so valuable, that we noders are forced to store their valuable data bytes forever?

0 sats \ 0 replies \ @udiWertheimer 16h

deleted by author

21 sats \ 0 replies \ @BITC0IN 14h

which core dev asked you to open this PR ?

110 sats \ 1 reply \ @tidwell OP 19h

What does "standardness mean" in reference to OP_RETURNs?

110 sats \ 0 replies \ @Murch fwd 19h

Bitcoin Core does not accept "non-standard transactions" into its mempool. Bitcoin Core 29.0 and earlier consider transactions with more than one OP_RETURN output or an OP_RETURN output of more than 80 bytes of data payload non-standard.

110 sats \ 1 reply \ @tidwell OP 19h

Will more than 1 OP_RETURN per transaction be possible if this PR gets merged?

110 sats \ 0 replies \ @Murch fwd 19h

Neither the count nor the size of OP_RETURN outputs is limited at the consensus level, so all nodes accept such transactions when they appear in blocks.

Currently, Bitcoin Core does not accept transactions with more than one OP_RETURN output to its mempool.

Peter Todd’s pull request proposes to allow transactions with multiple OP_RETURN outputs into the mempool.

110 sats \ 1 reply \ @tidwell OP 19h

What are the current OP_RETURN limits and what restrictions are being lifted?

110 sats \ 0 replies \ @Murch fwd 19h

Bitcoin Core 29.0 or earlier do not accept transactions with more than one OP_RETURN output or with an OP_RETURN output of more than 80 bytes of data payload to its mempool. Neither the count nor the size is limited at the consensus level. Peter Todd’s pull request proposes to drop both the limit on the count of OP_RETURN outputs and to drop the limit on the data payload.

110 sats \ 1 reply \ @tidwell OP 19h

Won't spammers abuse large OP_RETURNs to bloat the blockchain and make IBD take longer?

189 sats \ 0 replies \ @Murch fwd 19h

OP_RETURN data appears in output scripts. Output scripts are not subject to segwit’s witness discount. Per the block weight limit of segwit, we can have up to 4 MB of witness data, but only up to 1 MB of any other data in blocks. Output scripts are part of the other data.

Adding more output script data to blocks would result in smaller blocks. As OP_RETURN outputs require little computation to validate, OP_RETURN data would not slow down IBD.

110 sats \ 1 reply \ @tidwell OP 19h

Shouldn't we be fighting spam, why are we making policies less strict, shouldn't we be making them more strict?

510 sats \ 0 replies \ @Murch fwd 15h

While most Bitcoin Core contributors do not seem particularly excited about ordinals, inscriptions, runes, or similar projects, most of them appear to agree that the ability to embed data in the Bitcoin blockchain is a product of other characteristics of the Bitcoin network such as censorship resistance and a flexible scripting system.

Fighting "spam" transactions at the mempool policy level is ineffective, especially when such transactions have spent over $280M in transaction fees in the past two years which translates to plenty of financial incentive for mining pools to accept such (consensus-valid!) transactions out-of-band to pad their revenue.

The only way to properly make inroads on curbing spam would be to soft fork out the spam mechanisms. However, even going back to a small amount of whitelisted output script templates would not prevent data payloads in fake pubkeys or fake public key hashes, signatures per grinding, or other transaction fields that can hold arbitrary data.

When inscriptions were discussed as a concern for the Bitcoin network at a Bitcoin Core contributor meeting, the prevalent position was that making this quixotic fight the main priority of the project was not the best use of the project’s limited resources.

88 sats \ 2 replies \ @tidwell OP 19h

Are current relay and mempool policies effective for filtering out spam transactions?

21 sats \ 0 replies \ @Filiprogrammer 19h

The default mempool policies in Bitcoin Core are effective at preventing OP_RETURN outputs with more than 80 bytes of data. They are NOT effective at preventing OP_FALSE OP_IF ... OP_ENDIF (inscriptions) and fake public keys.

10 sats \ 0 replies \ @Murch fwd 16h

Transactions have been shown to somewhat reliably propagate to all nodes that accept them if at least 10% of the node population accept them to their mempool. Even a strong majority of the nodes of up to 90% of all nodes would have little to no impact on the propagation of consensus valid non-standard transactions relayed by the other 10% of the nodes..

Additionally, Libre Relay nodes, an implementation with less strict mempool policy than Bitcoin Core, preferentially peer with other Libre Relay nodes which means that they effectively relay transactions among each other even with much smaller network penetration, and some mining-pools accept direct submissions through web interfactes or APIs that do not rely at all on network propagation.

52 sats \ 5 replies \ @DarthCoin 19h

What will be the worst case scenario if users still could set their own limits for OP_RETURN?

321 sats \ 4 replies \ @Murch fwd 19h

Since transactions with larger OP_RETURN outputs or multiple OP_RETURN outputs are consensus valid, they will appear in blocks as long as they find their way to mining pools and mining pools choose to include them. Any nodes that don’t allow such transactions in their mempool will download them twice: once when the transaction is first offered to them by a peer, where they download it, evaluate it, and drop it due to their mempool policy, and then a second time when they receive the block announcement that includes the transaction.

Whenever nodes are missing transactions from a compact block announcement, they have to request the missing transactions which increases the latency until they can relay the block. The relay is delayed more when large transactions are missing. Nodes that run a mempool policy that is stricter than what regularly appears in blocks therefore use more bandwidth and relay blocks more slowly.

Slower block propagation benefits larger mining pools by increasing the number of stale blocks and delaying other miners in switching to the new chaintip. Bigger miners disproportionally win over competing blocks and the block author doesn’t suffer from the propagation delay when a block is found.

637 sats \ 3 replies \ @028559d218 18h

Whenever nodes are missing transactions from a compact block announcement, they have to request the missing transactions which increases the latency until they can relay the block. The relay is delayed more when large transactions are missing. Nodes that run a mempool policy that is stricter than what regularly appears in blocks therefore use more bandwidth and relay blocks more slowly.

For what it's worth, to people who are far more influential... There is a growing 'army' of folks who want to run more restrictive mempool policies to 'kill the spam'. Anti-ordinals, anti-memecoins, anti-BRCs etc... This is preached nonstop over and over, just do 'x' and you can stop the spam. "It's your memepool do X" etc etc.

What some of these "educators" don't explain however... is what you just said. About increasing latency, delay, bandwidth, speed at which blocks are relayed, miner centralization etc.

People are free to run whatever they want... but some of the "influencers" in the space only tell half the story or don't explain some of the downsides. It's like 'do this it's good' but without explaining why 'that' may not be a great idea. Thank you guys

1 sat \ 0 replies \ @DarthCoin 18h

good point

0 sats \ 0 replies \ @optimism 35m

Right! However, this is not a static situation as this is fully solveable with a relatively small amount of code: if people are truly serious about filtering, they could simply add a "purgatory" inside the mempool (or outside it, that doesn't matter) where all the crap lives that one does not want to relay or mine, but is still valid for (a) new txn inputs (where the new txns automatically end up in purgatory too unless the offending parent gets mined) and (b) compactblock reconstruction.

0 sats \ 0 replies \ @dwami 6h

good point 2

150 sats \ 1 reply \ @DarthCoin 5h

What was the main reason /concern to add this PR?
If the concern was that the blockchain size is too big for IBD, can we let things "AS IS" but somehow "archive" the past blocks, let's say pre-2017-fork era? And those who still want to use UTXOs from that era, could just do a simple migration or something ?
What will happen if we do nothing?

100 sats \ 0 replies \ @kevin_lightning 10m

The main reason for the PR (in my opinion) is that it achieves harm reduction. Similar to how local governments might provide a drug addict clean needles, giving data embedders the option to utilize OP_RETURN is better than having them stuff witnesses. This is because (1) OP_RETURN is provably unspendable and does not bloat the UTXO set and (2) does not leave dust outputs behind like witness stuffing (i.e. inscriptions). Secondly, removing the limit reduces the need for nodes to need to pull transactions at block-sync time because the next block will be made up of transactions already in your local mempool. Finally, because mining pools don't care about standardness, relay should not either. I think it was gmax that said what is relayed should closely match what is mined.
IBD solutions already exist today. I forgot the name of one of them but it essentially has UTXO set hints that allow you to parallelize the process of sync. This is the main reason why IBD is slow today, and if you setup a node from scratch you'll see that CPU/networking are not utilized to their full potential. Libbitcoin is another example of how parallelizing can make it such that your network speed is the bottleneck for sync.
If we do nothing then block updates are slightly worse for everyone as mentioned before. Additionally, if your code relies on mempool estimates for fees it will have a less accurate prediction of what to use for a fee rate. It would be similar to someone running the ordisrespector patch. Even if the transactions they don't like are not in their own mempool, they will need to store it anyway when a block is mined that contains them. Finally, if we do nothing there is a very real likelihood that a third party may resort to VERY BAD data storage methods like Bitcoin Stamps which utilize fake pubkeys and stuff data in them. These are much worse because they permanently bloat the UTXO set with each transaction created.

52 sats \ 1 reply \ @DarthCoin 19h

If OP_RETURN still cannot stop all the garbage, why is so important to remove it? Does it affect future development / improvements for LN ?

331 sats \ 0 replies \ @Murch fwd 18h

There are currently three ways of embedding data in the Bitcoin blockchain in use.

Inscriptions are written to an unexecuted branch of a taproot leaf script. This data appears in the witness stack of inputs. Witness data is only validated once when a node first validates a transaction’s scripts and is stored as part of the full blockchain record. When a pruning node performs IBD using the assumevalid option, witness data doesn’t have to be downloaded or evaluated at all. Witness data is discounted by 75% compared to other transaction data, but is malleable until a transaction is confirmed.
OP_RETURN data appears in the output script. OP_RETURN outputs are only validated once when the node first sees the transaction. The data in output scripts is not discounted and not malleable, as signatures on the inputs generally commit to the exact output scripts. As OP_RETURN outputs are unspendable, they are stored as part of the transaction in the blockchain data, but do not get added to the UTXO set.
Some schemes (e.g., Stamps) embed data in payment output scripts using either fake public keys or fake hashes. The data for output scripts is not discounted. As these output scripts are not clearly unspendable, these output scripts must be retained in the UTXO set.

Citrea recently announced that they plan to write data to payment outputs because they need non-malleable transaction data that gets confirmed timely in excess of the current OP_RETURN standardness limit. As the use of payment output scripts cannot be easily prevented, encouraging them to use OP_RETURN outputs instead would be harm reduction as at least the data would not be written to the UTXO set that every node has to retain forever.

The proponents in the mailing list thread and pull request further argue that it is more expensive to write large data payloads to OP_RETURN outputs than inscriptions and therefore use cases that already use inscriptions are not incentivized to use OP_RETURN. The break-even point for that appears to be 143 bytes above which payloads are more expensive to be embedded into OP_RETURN outputs.

I am not aware of any effects on LN development.

110 sats \ 3 replies \ @tidwell OP 19h

Will Taproot wizards and other spam companies and projects start using OP_RETURN to put jpegs on the blockchain?

242 sats \ 0 replies \ @rijndael 16h

I can't speak for the "spam companies and projects", but as far as we're concerned:

I'm not going to emphatically say "no" because who knows, maybe in the future we'll have some application where it makes sense but we currently do not. We have released and sold two inscription collections (that both put data in witness data). In both of those cases, it's not clear to me that having the data in OP_RETURNs would have been better. The main reason we put the data in witness data was for compatibility with the ordinals protocol. Our collectors want to be able to manage, store, and trade our collection in wallets they're already using -- and there are several ordinals-specific wallets out there, and any wallet with coin control could technically be used. You could add opreturns to ordinals, but it would be weird. imo, having inscription data in the input instead of the output makes the protocol cleaner and easier to implement.

So for our collections, compatibility is a bigger concern than something like the witness discount. High-value inscriptions are actually reasonably price-insensitive when we're talking about a 4x cost premium. We did a LOT of work on Quantum Cats to bring the cost down, but that was by a factor of about 100, not 4.

Outside of digital collectables, we've done a lot of work with OP_RETURNs holding data commitments for multi-transaction protocols using OP_CAT or other covenants. In those cases, usually we're putting one or two merkle roots and maybe a little metadata tag in an opreturn. So we actually haven't felt any real pain with the 80-byte limit. We actually run into consensus limits more often than we run into the OP_RETURN limit.

In general, if we did want to stick a bunch of data into an opreturn it would probably be something where:

we are not inspecting it in a future transaction (a la the OP_CAT state caboose trick)
it's something where either its an op_return-specific protocol or something other than ordinals (maybe something we cook up, maybe something our customers want)
its something where we really care about malleability (opreturns get covered by SIGHASH_ALL, witness data does not)

Nothing currently fits that bill, so I don't think so, but you never know. Maybe some of the people mad about this have a fun idea they can share.

21 sats \ 0 replies \ @udiWertheimer 17h

i don’t know… when it comes to our so-called “spam” work, it’s supposed to have cultural/sentimental value to some people

for example, for some people, a wizard jpeg is a way to express their love for bitcoin

it’s hard to predict if under some circumstance OP_RETURN will somehow increase the cultural/sentimental value of some jpeg, but my intuition is it probably will not?

then again, if for some reason it does, you can expect a lot of people will do that. from that standpoint, for those who for some reason want to avoid “spam”, it would make more sense not to remove OP_RETURN limits, to prevent the possibility that collectors ascribe some cultural/sentimental value to that in the future

10 sats \ 0 replies \ @Murch fwd 16h

To add a data payload via OP_RETURN, you have to add an additional output to a transaction. This requires 11 bytes of transaction data overhead. The data is not subject to segwit’s witness discount.

Vojtěch Strnad shows that inscriptions have at least 118.75 vB overhead. However, the data payload of inscriptions is subject to segwit’s witness discount.

According to Strnad‘s calculation, data payloads of 143 bytes or larger are cheaper with inscriptions. It would therefore only make sense for small payloads to move to OP_RETURN, and it seems economically unattractive to prefer OP_RETURN outputs over inscriptions to embed images in the blockchain.

10 sats \ 5 replies \ @javier 17h

Is there any estimation on how much would this affect fees for the average user, considering external projects (like Citrea) using it? Any possibility that this could saturate the mempool and boost fees beyond reasonable?

131 sats \ 4 replies \ @Murch fwd 15h

Citrea is ramping up to launch a rollup on Bitcoin that would use Bitcoin as the data availability layer. It does not require a consensus change to deploy, i.e., they don’t need to ask for permission. I did not study their protocol in detail previously. Skimming their technical specs, they mention that one type of proof is committed every ten minutes (i.e. 144 txs per day), but I also read that they store all necessary data on Bitcoin, therefore it is not clear to me whether there are more transactions that would write to the Bitcoin blockchain.

If it is just those 144 txs per day, their scheme would be unlikely to significantly impact the fees for other users, but I’ve previously seen an overview of dozens of other similar projects in the making (probably with various degree of success), so there may be multiple other schemes in the future for which we’d prefer that if they must, they only write to the blockchain and not both the UTXO set and the blockchain.

0 sats \ 3 replies \ @javier 15h

Ok, so just another speculative question, answer if you want: so the final objective of all of this is to enable proper Citrea operation, which will imply bringing Defi and nUSD (similar to Tether) directly to the Bitcoin blockchain without the need of a sidechain?

50 sats \ 2 replies \ @Murch fwd 15h

No, that is a misunderstanding.

From what I can see per a cursory internet search, their testnet is about a year old and has over 40,000 txs per day. It looks like Citrea is going to launch regardless.

The only aspect of this that ties into the OP_RETURN debate seems to be that the change could convince them to write their data only to the blockchain, whereas they are currently planning to write data to both the blockchain and the UTXO set.

0 sats \ 1 reply \ @028559d218 12h

40,000 a day is 1666 an hour or 277 a block. With 3000 other transactions a block that's... >9% of each block?

0 sats \ 0 replies \ @Murch fwd 9h

It's a Rollup, so I'd hope they're not actually storing all data on Bitcoin?

reply on another page

10 sats \ 5 replies \ @tidwell OP 19h

What makes a UTXO unprunable? Which projects are making unprunable UTXOs?

52 sats \ 0 replies \ @Murch fwd 15h

The UTXO set represents all spendable pieces of Bitcoin. A fullnode must have all UTXOs in order to be able to validate transactions. If some nodes were to discard some UTXOs and these UTXOs later get spent in a transaction, the network would fork as some nodes follow the blockchain in which the coins get spent and others would start forming an alternative chaintip.

There have been several cases of "blockchain graffiti" in which messages were left in pubkey hashes, and counterparty/Stamps deliberately used 1-of-3 bare multisig outputs to store data in two of the public keys (leaving the UTXO spendable per the third key). Recently, Citrea announced that they would store some data in pubkey hashes to embed non-malleable data in transactions with timely confirmation. A part of the motivation for dropping the OP_RETURN limit is that some consider it harm reduction to allow OP_RETURN payloads of 100 bytes instead of Citrea forging ahead with writing permanently to the UTXO set.

0 sats \ 3 replies \ @Filiprogrammer 17h

What makes a UTXO unprunable?

Any non-zero unspent transaction output that is not provably unspendable.

An output script starting with OP_RETURN is provably unspendable, so it can be pruned.

But an output with a fake public key or fake script hash (such as produced by STAMPS) is unspendable, but that's not always obvious. Thus these outputs must be retained in the UTXO set. These are the most harmful ones.

31 sats \ 2 replies \ @Murch fwd 16h

Mostly right, but…

Any non-zero unspent transaction output that is not provably unspendable.

…UTXOs are allowed to have an amount of 0 per consensus rules, the dust limit is also just a mempool policy.

0 sats \ 1 reply \ @Filiprogrammer 15h

Are you saying that zero amount UTXOs are retained in the UTXO set?

20 sats \ 0 replies \ @Murch fwd 15h

Yes, it is consensus-valid to create and spend UTXOs with an amount of 0. Therefore, any full node must retain them to not potentially be forked off the network.

110 sats \ 2 replies \ @tidwell OP 19h

What can we do to stop spam at the consensus layer of Bitcoin?

42 sats \ 0 replies \ @petertodd 17h

https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/QwkPB2HtEQAJ

tl;dr: you could make data publication much more expensive by requiring transactions to prove that data in them isn't arbitrary. But even that will not totally stop data publication. Also, not all “spam” requires data to be published.

10 sats \ 0 replies \ @Murch fwd 16h

You would have to try to forbid the spam via consensus rules, i.e. soft fork it out.

This would very quickly boil down to us choosing between having a flexible scripting system or not having spam transactions. Even if we restricted ourselves to whitelisting only specific single-sig payment schemes and forbidding all other transaction types, it would be possible to embed data in other transaction fields like signatures, public keys, or pubkey hashes. The trade-off seems rather unattractive to me.

110 sats \ 1 reply \ @tidwell OP 17h

A concern from x from a technical bitcoiner:

"If we open the shitcoin floodgates, which is what removing the opreturn limits does, then fees will go high and stay high forever, drowning out all legitimate onchain activity.

Bitcoin will be impossible to use permissionlessly at that point."

Murch please address this concern.

20 sats \ 0 replies \ @Murch fwd 16h

We have had multiple phases in Bitcoin’s history in which colored coin protocols, NFTs, or other schemes started using Bitcoin as a data layer. While some of them temporarily increased demand for blockspace, the mempool has so far always emptied eventually. Currently, the one-week average feerate in blocks is below 4 satoshis/virtualbyte.

OP_RETURNs are more expensive than inscriptions for larger amounts of data, and the data payload is not subject to segwit’s witness discount. Previous uses of OP_RETURN were shortlived as they became to expensive for the operators and either switched to other networks or were optimized out of existence. It is not clear to me what scenario the writer is picturing in which loosening the OP_RETURN limits would lead to a substantial amount of OP_RETURN data that could be classified as "opening the shitcoin floodgates".

31 sats \ 1 reply \ @tidwell OP 19h

If we prevent these transaction from going into our mempools doesn't that prevent or delay these spam transactions from being mined therefore discouraging the spammers?

31 sats \ 0 replies \ @Murch fwd 16h

Yes, in the sense that when you configure your node to have a more strict mempool policy than that of its peers, it will not add offending transactions to its mempool, and therefore also not relay them.

However, each node makes at least 8 outbound connections through which transactions are relayed, and listening nodes can even have more than 100 connections. A single peer announcing transactions is sufficient for a node to hear about them, so it is sufficient for about 10% of nodes to relay transactions for them to reliably reach miners that want them.

In conclusion, your node might not be participating in the relay of such transactions, but the relay of offending transactions is only prevent if almost all nodes on the network participate.

35 sats \ 0 replies \ @tidwell OP 19h

Is it possible to stop the abuse of payment outputs (i.e., bare multisig, fake pubkeys, and fake pubkey hashes) that are used to embed data, thereby creating unprunable UTXOs that bloat the UTXO set?

21 sats \ 0 replies \ @tidwell OP 19h

Is it possible to stop abuse of witness data? If so, how? (i.e ordinal theory inscriptions, "jpegs").

21 sats \ 0 replies \ @tidwell OP 19h

Is there any conflict of interest with Bitcoin Core and companies like Citrea, in ref to this PR?

10 sats \ 3 replies \ @tidwell OP 19h

Was this PR initially proposed because of Citrea BitVM needs? If so don't they only need a slight bump in OP_RETURN size, why is it being proposed to make the size unrestricted?

20 sats \ 2 replies \ @Murch fwd 15h

Citrea does not require an increase of the OP_RETURN limit.

AFAIU, Citrea is planning to launch a ZK Rollup on Bitcoin. To that end, they intend to write a proof into the Bitcoin blockchain every ten minutes. This proof takes 100 bytes of data. Their current plan is to write that data into one OP_RETURN output accompanied by a fake pubkey hash. Outputs with fake pubkey hashes cannot be safely discarded, therefore this unspendable payment output would pollute the UTXO set for all times. This would just work for them with the currently established mempool policies.

One of the motivations for the pull request would be that it could be suggested to Citrea that they instead write all data to a single slightly larger OP_RETURN output and we at least do not incur the unspendable outputs in the UTXO set.

Overall, the OP_RETURN limit was introduced to guide the use of Bitcoin away from excessive blockspace use for data while the available blockspace was only partially demanded. In the past 27 months, there have only been a few block that have not been full, so undemanded blockspace is no longer a thing. OP_RETURN outputs would have to compete for blockspace with other transactions at all times. The limit is neither as important nor as effective today as when it was introduced. Instead of providing mining pools with a financial incentive to accept oversized OP_RETURN outputs out of band, and to have debates to slightly loosen the limit further every once in a while, it seems easier to get rid of the incentive and debates by dropping it altogether.

101 sats \ 1 reply \ @robin_linus 12h

To that end, they intend to write a proof into the Bitcoin blockchain every ten minutes. This proof takes 100 bytes of data. Their current plan is to write that data into one OP_RETURN output accompanied by a fake pubkey hash

That's a common misconception. Indeed, Citrea is frequently writing a state diff and a corresponding proof into the blockchain, but they are using inscriptions for that. Those OP_RETURN transactions are something different. They are used only in case of a dispute during pegout for watchtowers to provide a chainstate proof for a heavier chain than the one the operator claimed to be the canonical chain.

These OP_RETURN transactions likely never hit the chain because there are strong disincentives for operators to make any invalid claims. Thus, ironically, lifting the OP_RETURN limit hardly has any effect in practice. It barely effects the Citrea protocol and it likely doesn't effect what kinds of transactions we see in the chain.

0 sats \ 0 replies \ @anon 11h

Isn't this why they need it to be standard though? Because those transactions need to be reliable and can't afford to wait for friendly miner which may take longer than the thief.

10 sats \ 1 reply \ @ChrisS 19h

What is the difference between the utxo set, the mempool and the blockchain. How does that relate to how much "stress" is put on a nodes computing power and storage limitations when considering transactions with larger OP_return data. How does this change when storing data in OP_return output vs storing data in the witness data?

10 sats \ 0 replies \ @Murch fwd 18h

The UTXO set represents all spendable balances of Bitcoin users on the network. Every full node must retain the entire UTXO set.

The blockchain represents the entire transaction journal of the UTXO set. The blockchain is used by new nodes to work out the current UTXO set and converge on the shared state of the network. The network as a whole needs to retain the blockchain, but individual nodes may prune most of the blockchain data after IBD.

Each node maintains its own mempool to keep track of unconfirmed transactions. Nodes use the mempool to reconstruct the full block from compact block announcements, to build block templates for mining, to estimate feerates, and to announce unconfirmed transactions to their peers. Optimally, nodes retain all unconfirmed transactions in their mempools that are expected to appear in blocks to front-load transaction validation to speed up block validation and relay.

Both OP_RETURN outputs and witness data are only relevant to transaction validation and need to be retained for a full copy of the blockchain. Neither of the two is retained in the UTXO set. Data payloads in OP_RETURN outputs and witness stacks are cheap to validate as they both appear in unexecuted sections of scripts. Either will be pruned by pruned nodes when the node moves sufficiently far past the block containing the transaction.

10 sats \ 2 replies \ @ChrisS 19h

What is the difference in defining a transaction as valid versus defining a transaction as standard and why do we need this difference?

10 sats \ 1 reply \ @Murch fwd 19h

The consensus rules specify what a node must accept in a block. These rules must match perfectly across all node implementations. If a block or a transaction in a block are evaluated differently by some nodes, the network would experience a consensus failure as some nodes accept the block while others fork off.

A node’s mempool policy defines what the node will relay and consider for the block templates it produces. We use mempool policy to e.g. discourage transactions that are expensive to validate or might trigger security issues for some nodes, and the premature use of upgrade hooks. Generally, mempool policy is more strict than consensus rules and may diverge across nodes. When many nodes agree on mempool policy, it reduces the amount of bandwidth necessary to propagate transactions and blocks across the network, and reduces the overall latency of block propagation, because most nodes can reconstruct the full block from compact block announcements.

0 sats \ 0 replies \ @ChrisS 18h

Consensus rules define valid transactions and a nodes mempool policy defines what it considers standard? Are there any consensus rules surrounding the size of op_return?

10 sats \ 1 reply \ @tidwell OP 19h

Why would a spammer use OP_RETURN if it's cheaper to use Witness data to store arbitrary data?

10 sats \ 0 replies \ @Murch fwd 15h

OP_RETURN data is signed by the signatures in inputs, and therefore cannot be malleated, while at least the signatures in witness data are malleable. Some users also perceive OP_RETURN as the "correct/righteous" way to embed data.

OP_RETURN outputs are also slightly cheaper for small data payloads up to 143 bytes, but more expensive for bigger data payloads.

10 sats \ 1 reply \ @tidwell OP 19h

Won't large OP_RETURNs allow people to spam the mempool with 100kb transactions and mess up bitcoin for everyone by bloating the mempool and not allowing legitimate transactions in the mempool?

10 sats \ 0 replies \ @Murch fwd 16h

Bitcoin Core’s mempool data structure is limited to 300 MB by default. If a node’s mempool is full, it will start evicting the transactions with the lowest feerates. Transactions get into the mempools of nodes much the same way as they get into blocks: if they offer a higher feerate, they are added to the mempool, potentially displacing lower feerate transactions, whether they are big or small transactions.

OP_RETURN transactions do not have any advantage in the competition for blockspace, and OP_RETURN data appears in the output script. The output script is not subject to segwit’s witness data discount, and therefore each byte of OP_RETURN data incurs 1 kvB (4 wu) of blockspace.

0 sats \ 0 replies \ @flat24 34m

I think that Bitcoin should stay as it is, to be just money, if people 👥 want to do other things should use other networks, in the end they are the other shit.

Is it true that this type of update could affect Bitcoin's decentralization?

0 sats \ 0 replies \ @a6c4385b38 1h freebie

I read actual types of non-standard tx are discussed here https://b10c.me/observations/09-non-standard-transactions/

looks like most types are not relevant to op-return.

Could this PR be the beginning of reducing other mempool restrictions?.. also asking myself. With Libre Relay seems not that important now

0 sats \ 0 replies \ @Bitcoiner1 4h

What do you support? Unlimited Core or Knots further restricting OP_RETURN?

0 sats \ 0 replies \ @DarthCoin 5h

If there will be a hard fork resulted from this PR (split chain like in 2017), what will happen with existing LN channels? Will exist on both chains with 2 LNs ? that will be some kind of madness... It's a rhetorical question, I know.

0 sats \ 1 reply \ @aPolitical 7h

Was the @optimism network down?

0 sats \ 0 replies \ @optimism 1h

Only for flight mode a few times per year.

0 sats \ 0 replies \ @joseph_at_nostr_fan 9h

Thank you for the most balanced, honest, and technically sound discussion on the whole OP_RETURN subject.

0 sats \ 0 replies \ @unschooled 13h

If relaxing op_return standardness limit seeks to make 'spam' prunable, then what are proponents of this change assuming about the long-term feasibility of running a 'full' (unpruned) bitcoin node?

0 sats \ 0 replies \ @Mishawaka 17h

Are there any services/APIs for searching through OP_RETURN text?

0 sats \ 0 replies \ @tidwell OP 19h

Culture is what protects Bitcoin from external forces, shouldn't non-technical arguments be valid when considering these types of changes?

0 sats \ 0 replies \ @tidwell OP 19h

Shouldn't we debate the controversy of this PR on Github since it's where the code gets merged to make these changes?

0 sats \ 0 replies \ @tidwell OP 19h

Is allowing standardness for larger OP_RETURNs a slippery slope? If we allow this won't we continue to allow things that make bitcoin less for money and more for arbitrary data?

0 sats \ 0 replies \ @tidwell OP 19h

What does it mean when someone says "Fix the Filters"?

0 sats \ 0 replies \ @tidwell OP 19h

deleted by author