From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "vjudeu@gazeta•pl" <vjudeu@gazeta•pl>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
Date: Wed, 06 Apr 2022 00:43:23 +0000 [thread overview]
Message-ID: <lecHK-Gt-prJf9W_9w1Ps6NWo8akVHYQWHEVbJ0Jdf89JhEmDO-u6y4_TXmtViv6t59svUdg2ACUfzBmFn58yEbL-eRpuS5ag5nDAR8u6Vg=@protonmail.com> (raw)
In-Reply-To: <160141998-7e37e8b4e29d41a79eddfe20e9b8c75f@pmq4v.m5r2.onet>
Good morning vjudeu,
> When I see more and more proposals like this, where things are commited to Taproot outputs, then I think we should start designing "miner-based commitments". If someone is going to make a Bitcoin transaction and add a commitment 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 with 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 things, 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 would allow making commitments in a standardized way. We always have one coinbase transaction for each block, it is consensus rule. So, by tweaking single public key in the coinbase transaction, it is possible to fit all commitments 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 standardize 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 some 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 payments 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 might then be induced to censor such commitments).
In short: there is no such thing as "other case that person would make no transcation at all", because you have to somehow bribe miners to include the commitment to your data, and you might as well use existing mechanisms (transactions that implicitly pay fees) for your data commitment, and get better censorship-resistance and privacy.
Nothing really prevents any transaction-based scheme from having multiple users that aggregate their data (losing privacy but aggregating their fees) to make a sum commitment and just make a single transaction that pays for the privilege of committing to the sum commitment.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2022-04-06 0:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 20:23 vjudeu
2022-04-06 0:43 ` ZmnSCPxj [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-04-11 0:30 Bram Cohen
2022-04-11 18:21 ` Olaoluwa Osuntokun
2022-04-11 21:29 ` Bram Cohen
2022-04-05 15:06 Olaoluwa Osuntokun
2022-04-07 17:14 ` Ruben Somsen
2022-04-08 17:48 ` Olaoluwa Osuntokun
2022-04-10 16:51 ` Ruben Somsen
2022-04-11 19:51 ` Olaoluwa Osuntokun
2022-04-15 13:14 ` Ruben Somsen
2022-04-16 2:43 ` Olaoluwa Osuntokun
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='lecHK-Gt-prJf9W_9w1Ps6NWo8akVHYQWHEVbJ0Jdf89JhEmDO-u6y4_TXmtViv6t59svUdg2ACUfzBmFn58yEbL-eRpuS5ag5nDAR8u6Vg=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=vjudeu@gazeta$(echo .)pl \
/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