Date: Wed, 06 Apr 2022 00:43:23 +0000
To: "vjudeu@gazeta.pl" <vjudeu@gazeta.pl>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <lecHK-Gt-prJf9W_9w1Ps6NWo8akVHYQWHEVbJ0Jdf89JhEmDO-u6y4_TXmtViv6t59svUdg2ACUfzBmFn58yEbL-eRpuS5ag5nDAR8u6Vg=@protonmail.com>
In-Reply-To: <160141998-7e37e8b4e29d41a79eddfe20e9b8c75f@pmq4v.m5r2.onet>
References: <160141998-7e37e8b4e29d41a79eddfe20e9b8c75f@pmq4v.m5r2.onet>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
Precedence: list

Good morning vjudeu,

> When I see more and more proposals like this, where things are commited t=
o Taproot outputs, then I think we should start designing "miner-based comm=
itments". If someone is going to make a Bitcoin transaction and add a commi=
tment for zero cost, just by tweaking some Taproot public key, then it is a=
 benefit for the network, because then it is possible to get more things wi=
th no additional bytes. Instead of doing "transaction-only", people can do =
"transaction+commitment" for the same cost, that use case is positive.
>
> But if someone is going to make a Bitcoin transaction only to commit thin=
gs, where in other case that person would make no transaction at all, then =
I think we should have some mechanism for "miner-based commitments" that wo=
uld allow making commitments in a standardized way. We always have one coin=
base transaction for each block, it is consensus rule. So, by tweaking sing=
le public key in the coinbase transaction, it is possible to fit all commit=
ments in one tweaked key, and even make it logarithmic by forming a tree of=
 commitments.
>
> I think we cannot control user-based commitments, but maybe we should sta=
ndardize miner-based commitments, for example to have a sorted merkle tree =
of commitments. Then, it would be possible to check if some commitment is a=
 part of that tree or not (if it is always sorted, then it is present at so=
me specified position or not, so by forming SPV-proof we can quickly prove,=
 if some commitment is or is not a part of some miner Taproot commitment).

You might consider implementing `OP_BRIBE` from Drivechains, then.

Note that if you *want* to have some data committed on the blockchain, you =
*have to* pay for the privilege of doing so --- miners are not obligated to=
 put a commitment to *your* data on the coinbase for free.
Thus, any miner-based commitment needs to have a mechanism to offer payment=
s to miners to include your commitment.

You might as well just use a transaction, and not tell miners that you want=
 to commit data using some tweak of the public key (because the miners migh=
t then be induced to censor such commitments).

In short: there is no such thing as "other case that person would make no t=
ranscation at all", because you have to somehow bribe miners to include the=
 commitment to your data, and you might as well use existing mechanisms (tr=
ansactions that implicitly pay fees) for your data commitment, and get bett=
er censorship-resistance and privacy.

Nothing really prevents any transaction-based scheme from having multiple u=
sers that aggregate their data (losing privacy but aggregating their fees) =
to make a sum commitment and just make a single transaction that pays for t=
he privilege of committing to the sum commitment.

Regards,
ZmnSCPxj