Велеслав [ARCHIVE] on Nostr: 📅 Original date posted:2022-07-17 📝 Original message:Hello List, I have been ...
📅 Original date posted:2022-07-17
📝 Original message:Hello List,
I have been pondering this problem for some time and have not yet come up with an elegant solution, so I am asking here to get more perspective.
There are many usecases for proof of burn. The current working solution is to use OP_RETURN with some application specific data.
However, this is limited because block space is finite, and although the use of block space itself is an implicit form of burn and can be used in the economic calculation of the burn, it is still a fundamental scalability constraint.
It would be great to have some sort of second layer protocol where micro-burns could be instantly exchanged and public proofs generated. Something like the Lightning Network, but with public evidence of burns.
I was thinking of pre-committing a larger OP_RETURN burn in the blockchain, with an additional output that would include a merkel tree with sparse summation (see Taro), but I haven't found a solution to the double-spend problem. I see that the space in this tree can be oversold before it is committed to the blockchain.
This makes me wonder if there really is no solution other than to use a blockchain. For example, a liquid type sidechain, where the pre-commitments being burned are a kind of pledge, and the resulting merkel tree is built and fixed via a bail-out sidechain mechanism.
Burns can be performed on the side chain at a very high frequency, and the side chain can end up fixing these burns back into the main chain within some effective merkel tree proof structure.
All in all, I would like some kind of solution that would be similar to buying a micro-burn using the Lightning network milisatoshis, and then quickly and reliably obtaining a unique and valid burn proof that is cheap to verify. Is something like this possible?
Kind Regards,Veleslav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220717/977aca8e/attachment.html>;
📝 Original message:Hello List,
I have been pondering this problem for some time and have not yet come up with an elegant solution, so I am asking here to get more perspective.
There are many usecases for proof of burn. The current working solution is to use OP_RETURN with some application specific data.
However, this is limited because block space is finite, and although the use of block space itself is an implicit form of burn and can be used in the economic calculation of the burn, it is still a fundamental scalability constraint.
It would be great to have some sort of second layer protocol where micro-burns could be instantly exchanged and public proofs generated. Something like the Lightning Network, but with public evidence of burns.
I was thinking of pre-committing a larger OP_RETURN burn in the blockchain, with an additional output that would include a merkel tree with sparse summation (see Taro), but I haven't found a solution to the double-spend problem. I see that the space in this tree can be oversold before it is committed to the blockchain.
This makes me wonder if there really is no solution other than to use a blockchain. For example, a liquid type sidechain, where the pre-commitments being burned are a kind of pledge, and the resulting merkel tree is built and fixed via a bail-out sidechain mechanism.
Burns can be performed on the side chain at a very high frequency, and the side chain can end up fixing these burns back into the main chain within some effective merkel tree proof structure.
All in all, I would like some kind of solution that would be similar to buying a micro-burn using the Lightning network milisatoshis, and then quickly and reliably obtaining a unique and valid burn proof that is cheap to verify. Is something like this possible?
Kind Regards,Veleslav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220717/977aca8e/attachment.html>;