Re: [bitcoin-dev] How to do Proof of Micro-Burn?

From: Ruben Somsen <rsomsen@gmail•com>
To: Велеслав <veleslav.bips@protonmail•com>,
	"Bitcoin Protocol Discussion"
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] How to do Proof of Micro-Burn?
Date: Sun, 17 Jul 2022 22:40:33 +0200	[thread overview]
Message-ID: <CAPv7TjadLN0X31vdo6ATy_aYepbcykZ8Vp8ghQA9W-GEV4axmg@mail.gmail.com> (raw)
In-Reply-To: <OPZNUXvYVkB6kyu7Xvw5-lLIwwwftN_pz0iavHInWvQtQaxIzJhYQrx3dkITo9Yge02emrXY3obveywkH04dyAJdETIeeq9-zcH3DA7OxKs=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 4408 bytes --]

Hi Veleslav,

This is something I've been interested in.

What you need is a basic merkle sum tree (not sparse), so if e.g. you want
to burn 10, 20, 30 and 40 sats for separate use cases, in a single tx you
can burn 100 sats and commit to a tree with four leaves, and the merkle
proof contains the values. E.g. the rightmost leaf is 40 and has 30 as its
neighbor, and moves up to a node of 70 which has 30 (=10+20) as its
neighbor, totalling 100.

The leaf hash needs to commit to the intent/recipient of the burn, so that
way you can't "double spend" the burn by reusing it for more than one
purpose.

You could outsource the burn to an aggregating third party by paying them
e.g. over LN but it won't be atomic, so they could walk away with your
payment without actually following through with the burn (but presumably
take a reputational hit).

As I believe you already realized, while an op_return is needed (or rather,
preferred) to burn, you don't necessarily have to put the hash there and
can thus save some bytes. One possible place to commit the root hash is in
a double taproot commitment in the change output. So while taproot is Q =
P + hash(Q||mast)*G, you'd commit the root in P such that P = N +
hash(N||burn_tree_root)*G. What's important is that the location is fully
deterministic, in order to ensure there isn't more than one tree (which
would be yet another way to "double spend").

Finally, you can perform the burn on a spacechain[0] (basically a
"sidechain" that has burned BTC as its native token) in order to pretty
much avoid using mainchain block space altogether, so it should scale much
better. It's worth noting that this fully supports SPV proofs, so the third
party you're proving the burn to doesn't have to run a full node (though
SPV may not be safe enough for big amounts).

To me this seems like a possible way to revitalize the original hashcash
use case, e.g. by only accepting emails which have an SPV proof of some
burned sats attached, or any other place where spam is an issue.

Cheers,
Ruben

[0] Spacechains:
https://gist.github.com/RubenSomsen/c9f0a92493e06b0e29acced61ca9f49a#spacechains

On Sun, Jul 17, 2022 at 9:41 PM Велеслав via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 7219 bytes --]