ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-05 📝 Original message:Good morning vjudeu, > ...
📅 Original date posted:2022-04-05
📝 Original message: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
📝 Original message: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