Recently I was reading some more about the PoX implementation and found this:
After this point, PoX is no longer active, and miners must burn all of their leader block commits. They do so by sending Bitcoin to the canonical burn address 1111111111111111111114oLvT2.
I am wondering, would it be possible to change the PoB mechanism used from one that sends bitcoin to a burn address to one that uses OP_RETURN outputs instead? My understanding is that bitcoin sent to a burn address must be forever stored in the UTXO set, thus contributing to permanent UTXO set bloat, whereas OP_RETURN outputs can be safely pruned by nodes since they are provably unspendable. For this reason, burning via OP_RETURN is generally considered the “bitcoin-friendly” way of burning BTC. I would like it if Stacks could be good bitcoin citizens and avoid bloating the UTXO set if possible. Thoughts?
In 2013, an easy way to add data to any Bitcoin transaction was introduced. By making standard a previously invalid script instruction, OP_RETURN, a Bitcoin user could add up to 40 bytes of data to his transactions.
Before the standardization this new output type, including data in the blockchain was not a straightforward task and involved using numerous bogus addresses to encode arbitrary data. The introduction this new output type made it easier and allowed Bitcoin nodes to prune this kind of outputs from their memory as they cannot be spent thereby limiting what developers called blockchain bloat.
cc and thanks to @jude who brought Stacks’ use of a burn address to my attention
I am bumping this thread to formally propose that all Stacks transactions that currently use an “unspendable address” for “burn” transactions be updated to use an OP_RETURN output instead.
As I describe in the OP, unspendable burn addresses create a negative externality on all bitcoin users by bloating the UTXO set. (In a recent discussion about another protocol that uses unspendable addresses, numerous Bitcoin Core devs called usage of such unspendable addresses “harmful” to bitcoin.) In contrast, OP_RETURN outputs do not bloat the UTXO set, and are therefore considered the “correct” or at least “bitcoin-friendly” way to burn BTC.
If there are no strong technical objections to this proposal then I will move on to drafting a SIP for its implementation.
Appendix A. Rationale for the status quo
One may reasonably ask: why does Stacks use an unspendable burn address rather than an OP_RETURN output to begin with? When asked that very question here on this forum, @judeanswered that it is because when he was first designing the system in 2015, he didn’t know OP_RETURN could be used to burn BTC.
In light of the knowledge that OP_RETURN can theoretically replace the use of burn addresses, we can now ask: is there anything that practically stops Stacks from using OP_RETURN instead of burn addresses today?
One thing could be Bitcoin Core standardness/policy rules: for example, if Stacks needs to have multiple OP_RETURN burn outputs in a single transaction, that would currently be a non-standard transaction. This would be useful to surface and communicate to the Bitcoin Core devs as they are actively reconsidering OP_RETURN standardness policies. If we need some non-standard OP_RETURN capability and can say that Stacks will (with some strong likelihood, given no ability to guarantee uptake by a decentralized network) take advantage of that change if/when it happens, then that would be another datapoint in favor of the change in Bitcoin Core and increase the likelihood that it actually happens, clearing the way for Stacks to make the switch to a less harmful burn mechanism.
I think that the block commit could be modified to do this and still have only one OP_RETURN, but I believe that an OP_RETURN output with non-zero value is currently considered non-standard, and I haven’t heard anyone talking about changing that, so that policy would need to change as well for this to work.
Bitcoin Core 0.12.0 defaults to relaying and mining null data outputs with up to 83 bytes with any number of data pushes, provided the total byte limit is not exceeded. There must still only be a single null data output and it must still pay exactly 0 satoshis.
Thanks for the input and pointer @brice! That documentation is incorrect. There is a default maxburnamountRPC setting that is applied locally when creating and sending a transaction but not a policy that is applied to other people’s transactions being relayed around the network. So if you set your local maxburnamount RPC setting to 100 BTC and send a tx with an OP_RETURN output value of 100≥[fee amount]>0 BTC and market fee rate then your node will broadcast it and other nodes will relay it and miners will mine it (under current Bitcoin Core standardness/policy defaults).
