vjudeu at gazeta.pl [ARCHIVE] on Nostr: 📅 Original date posted:2022-04-05 📝 Original message:When I see more and more ...
📅 Original date posted:2022-04-05
📝 Original message: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).
On 2022-04-05 15:06:03 user Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
Hi y'all,
I'm excited to publicly publish a new protocol I've been working on over the past few months: Taro. Taro is a Taproot Asset Representation Overlay which allows the issuance of normal and also collectible assets on the main Bitcoin chain. Taro uses the Taproot script tree to commit extra asset structured meta data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree or MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a sparse merkle tree, enabling things like easily verifiable asset supply proofs and also efficient proofs of non existence (eg: you prove to me you're no longer committing to the 1-of-1 holographic beefzard card during our swap). Taro asset transfers are then embedded in a virtual/overlay transaction graph which uses a chain of asset witnesses to provably track the transfer of assets across taproot outputs. Taro also has a scripting system, which allows for programmatic unlocking/transfer of assets. In the first version, the scripting system is actually a recursive instance of the Bitcoin Script Taproot VM, meaning anything that can be expressed in the latest version of Script can be expressed in the Taro scripting system. Future versions of the scripting system can introduce new functionality on the Taro layer, like covenants or other updates.
The Taro design also supports integration with the Lightning Network (BOLTs) as the scripting system can be used to emulate the existing HTLC structure, which allows for multi-hop transfers of Taro assets. Rather than modify the internal network, the protocol proposes to instead only recognize "assets at the edges", which means that only the sender+receiver actually need to know about and validate the assets. This deployment route means that we don't need to build up an entirely new network and liquidity for each asset. Instead, all asset transfers will utilize the Bitcoin backbone of the Lightning Network, which means that the internal routers just see Bitcoin transfers as normal, and don't even know about assets at the edges. As a result, increased demand for transfers of these assets as the edges (say like a USD stablecoin), which in will turn generate increased demand of LN capacity, result in more transfers, and also more routing revenue for the Bitcoin backbone nodes.
The set of BIPs are a multi-part suite, with the following breakdown:
* The main Taro protocol: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki
* The MS-SMT structure: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki
* The Taro VM: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki
* The Taro address format: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki
* The Taro Universe concept: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki
* The Taro flat file proof format: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki
Rather than post them all in line (as the text wouldn't fit in the allowed size limit), all the BIPs can be found above.
-- Laolu
📝 Original message: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).
On 2022-04-05 15:06:03 user Olaoluwa Osuntokun <laolu32 at gmail.com> wrote:
Hi y'all,
I'm excited to publicly publish a new protocol I've been working on over the past few months: Taro. Taro is a Taproot Asset Representation Overlay which allows the issuance of normal and also collectible assets on the main Bitcoin chain. Taro uses the Taproot script tree to commit extra asset structured meta data based on a hybrid merkle tree I call a Merkle Sum Sparse Merkle Tree or MS-SMT. An MS-SMT combined the properties of a merkle sum tree, with a sparse merkle tree, enabling things like easily verifiable asset supply proofs and also efficient proofs of non existence (eg: you prove to me you're no longer committing to the 1-of-1 holographic beefzard card during our swap). Taro asset transfers are then embedded in a virtual/overlay transaction graph which uses a chain of asset witnesses to provably track the transfer of assets across taproot outputs. Taro also has a scripting system, which allows for programmatic unlocking/transfer of assets. In the first version, the scripting system is actually a recursive instance of the Bitcoin Script Taproot VM, meaning anything that can be expressed in the latest version of Script can be expressed in the Taro scripting system. Future versions of the scripting system can introduce new functionality on the Taro layer, like covenants or other updates.
The Taro design also supports integration with the Lightning Network (BOLTs) as the scripting system can be used to emulate the existing HTLC structure, which allows for multi-hop transfers of Taro assets. Rather than modify the internal network, the protocol proposes to instead only recognize "assets at the edges", which means that only the sender+receiver actually need to know about and validate the assets. This deployment route means that we don't need to build up an entirely new network and liquidity for each asset. Instead, all asset transfers will utilize the Bitcoin backbone of the Lightning Network, which means that the internal routers just see Bitcoin transfers as normal, and don't even know about assets at the edges. As a result, increased demand for transfers of these assets as the edges (say like a USD stablecoin), which in will turn generate increased demand of LN capacity, result in more transfers, and also more routing revenue for the Bitcoin backbone nodes.
The set of BIPs are a multi-part suite, with the following breakdown:
* The main Taro protocol: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro.mediawiki
* The MS-SMT structure: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-ms-smt.mediawiki
* The Taro VM: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-vm.mediawiki
* The Taro address format: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki
* The Taro Universe concept: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-universe.mediawiki
* The Taro flat file proof format: https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-proof-file.mediawiki
Rather than post them all in line (as the text wouldn't fit in the allowed size limit), all the BIPs can be found above.
-- Laolu