On Wed, Jul 20, 2022 at 12:23:40AM +0200, Ruben Somsen via bitcoin-dev wrote:
> The goal is to burn multiple amounts (10, 20, 30, 40) in a single OP_RETURN
> (100) and specifically indicating how much of the total is intended for
> what use case. A merkle sum tree achieves this.
>
> (1a) 100
Good evening ZmnSCPxj,
>I suppose that means that the knower of `k` is a trusted party; it is
trusted to only issue commitments and not generate fake ones
Then you can reduce the scheme to just committing to K and having that key
sign whatever the burn was intended for. I doubt this is useful in
Good morning Ruben,
> Good evening ZmnSCPxj,
> Interesting attempt.
>
> >a * G + b * G + k * G
>
> Unfortunately I don't think this qualifies as a commitment, since one could
> trivially open the "commitment" to some uncommitted value x (e.g. a is set to
> x and b is set to a+b-x). Perhaps
Good evening ZmnSCPxj,
Interesting attempt.
>a * G + b * G + k * G
Unfortunately I don't think this qualifies as a commitment, since one could
trivially open the "commitment" to some uncommitted value x (e.g. a is set
to x and b is set to a+b-x). Perhaps you were thinking of Pedersen
Good morning Ruben and Veleslav,
> 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
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
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.
