From: Велеслав <veleslav.bips@protonmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] How to do Proof of Micro-Burn?
Date: Sun, 17 Jul 2022 13:28:23 +0000 [thread overview]
Message-ID: <OPZNUXvYVkB6kyu7Xvw5-lLIwwwftN_pz0iavHInWvQtQaxIzJhYQrx3dkITo9Yge02emrXY3obveywkH04dyAJdETIeeq9-zcH3DA7OxKs=@protonmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 2419 bytes --]
next reply other threads:[~2022-07-17 13:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-17 13:28 Велеслав [this message]
2022-07-17 20:40 ` Ruben Somsen
2022-07-17 22:34 ` ZmnSCPxj
2022-07-18 22:32 ` Ruben Somsen
2022-07-19 14:48 ` ZmnSCPxj
2022-07-19 22:23 ` Ruben Somsen
2022-07-19 23:13 ` Peter Todd
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='OPZNUXvYVkB6kyu7Xvw5-lLIwwwftN_pz0iavHInWvQtQaxIzJhYQrx3dkITo9Yge02emrXY3obveywkH04dyAJdETIeeq9-zcH3DA7OxKs=@protonmail.com' \
--to=veleslav.bips@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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