📅 Original date posted:2023-09-06
🗒️ Summary of this message: The Taproot Assets Protocol has been officially published, with various BIPs describing the data structure, validation rules, address format, and more. Highlights include test vectors, the Universe construct, and asset group keys. Versioning and re-org protection have also been implemented.
📝 Original message:
After more than a year of tinkering, iterating, simplifying, and
implementing, I'm excited to officially publish (and request BIP numbers
for) the Taproot Assets Protocol. Since the initial publishing we've
retained the same spec/document structure, with the addition of a new BIP
that describes the vPSBT format (which are PSBTs for the TAP layer). Each
BIP now also contains a set of comprehensive test vectors (to be further
expanded over time.
https://github.com/bitcoin/bips/pull/1489
As the complete set of documents is large, we omit them from this email.
The breakdown of the BIPs are as follows:
* `bip-tap-mssmt`: describes the MS-SMT (Merkle-Sum Sparse Merkle Tree)
data structure used to store assets and various proofs.
* `bip-tap`: describes the Taproot Assets Protocol validation and state
transition rules.
* `bip-tap-addr`: describes the address format used to send and receive
assets.
* `bip-tap-vm`: describes the initial version of the off-chain TAP VM used
to lock and unlock assets.
* `bip-tap-vpsbt`: describes a vPSBT (virtual PSBT) which is a series
custom types on top of the existing PSBT protocol to facilitate more
elaborate asset related transactions.
* `bip-tap-proof-file`: describes the flat file format which is used to
prove and verify the provenance of an asset
* `bip-tap-universe`: describes the Universe server construct, which is an
off-chain index into TAP data on-chain, used for: proof distribution,
asset boostraping, and asset transaction archiving.
Some highlights of the additions/modifications of the BIPs since the initial
drafts were published last year:
* Test JSON vectors for each BIP document now included.
* The Universe construct for initial verification of assets, distributing
asset proofs, and transaction archiving is now further specified. A
naive and tree based syncing algorithm, along with a standardized
REST/gRPC interface are now in place.
* The asset group key structure (formerly known as asset key families) has
been further developed. Group keys allow for the creation of assets that
support ongoing issuance. A valid witness of a group key during the
minting process allows otherwise disparate assets to be considered
fungible, and nested under the same sub-tree. A group key is itself just
a taproot output key. This enables complex issuance conditions such as:
multi-sig threshold, hash chain reveal, and any other conditions
expressible by script (and eventually beyond!).
* New versioning bytes across the protocol to ensure extensibility and
upgradability in a backwards compatible manner where possible. The asset
metadata format now has been re-worked to only commit to a hash of the
serialized meta data. Asset metadata can now also have structured data,
key-value or otherwise.
* Observance of re-org protection for asset proofs. The file format now
also uses an incremental hash function to reduce memory requirements
when added a new transition to the end of the file.
* Specification of the vPSBT protocol [1] which is the analogue of normal
PSBTs for the TAP layer. The packet format specifies custom key/value
pairs for the protocol describes an aggregate TAP transaction. After the
packet is signed by all participants, it's "anchored" into a normal
Bitcoin transaction by committing to the resulting output commitments
and witnesses.
We've also made significant advancements in our initial implementation [2],
with many wallets, explorers, services, and businesses working with us to
test and iterate on both the protocol and the implementation. We're actively
working on our next major release, which will be a major milestone towards
the eventual mainnet deployment of the protocol!
-- Laolu
[1]: https://lightning.engineering/posts/2023-06-14-virtual-psbt/
[2]: https://github.com/lightninglabs/taproot-assets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230906/f3a90b1f/attachment.html> 📅 Original date posted:2023-09-07
🗒️ Summary of this message: The Taproot Assets Protocol allows for the registration of non-Bitcoin assets on the Bitcoin blockchain, which can benefit the Bitcoin economy by expanding its use cases and increasing liquidity.
📝 Original message:
Hi Laolu,
Could you explain please how facilitating registering non-Bitcoin assets on
the Bitcoin blockchain is beneficial for the Bitcoin economy?
Thanks,
Zac
On Wed, 6 Sep 2023 at 21:02, Olaoluwa Osuntokun via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> After more than a year of tinkering, iterating, simplifying, and
> implementing, I'm excited to officially publish (and request BIP numbers
> for) the Taproot Assets Protocol. Since the initial publishing we've
> retained the same spec/document structure, with the addition of a new BIP
> that describes the vPSBT format (which are PSBTs for the TAP layer). Each
> BIP now also contains a set of comprehensive test vectors (to be further
> expanded over time.
>
> https://github.com/bitcoin/bips/pull/1489
>
> As the complete set of documents is large, we omit them from this email.
>
> The breakdown of the BIPs are as follows:
>
> * `bip-tap-mssmt`: describes the MS-SMT (Merkle-Sum Sparse Merkle Tree)
> data structure used to store assets and various proofs.
>
> * `bip-tap`: describes the Taproot Assets Protocol validation and state
> transition rules.
>
> * `bip-tap-addr`: describes the address format used to send and receive
> assets.
>
> * `bip-tap-vm`: describes the initial version of the off-chain TAP VM
> used
> to lock and unlock assets.
>
> * `bip-tap-vpsbt`: describes a vPSBT (virtual PSBT) which is a series
> custom types on top of the existing PSBT protocol to facilitate more
> elaborate asset related transactions.
>
> * `bip-tap-proof-file`: describes the flat file format which is used to
> prove and verify the provenance of an asset
>
> * `bip-tap-universe`: describes the Universe server construct, which is
> an
> off-chain index into TAP data on-chain, used for: proof distribution,
> asset boostraping, and asset transaction archiving.
>
> Some highlights of the additions/modifications of the BIPs since the
> initial
> drafts were published last year:
>
> * Test JSON vectors for each BIP document now included.
>
> * The Universe construct for initial verification of assets, distributing
> asset proofs, and transaction archiving is now further specified. A
> naive and tree based syncing algorithm, along with a standardized
> REST/gRPC interface are now in place.
>
> * The asset group key structure (formerly known as asset key families)
> has
> been further developed. Group keys allow for the creation of assets
> that
> support ongoing issuance. A valid witness of a group key during the
> minting process allows otherwise disparate assets to be considered
> fungible, and nested under the same sub-tree. A group key is itself
> just
> a taproot output key. This enables complex issuance conditions such as:
> multi-sig threshold, hash chain reveal, and any other conditions
> expressible by script (and eventually beyond!).
>
> * New versioning bytes across the protocol to ensure extensibility and
> upgradability in a backwards compatible manner where possible. The
> asset
> metadata format now has been re-worked to only commit to a hash of the
> serialized meta data. Asset metadata can now also have structured data,
> key-value or otherwise.
>
> * Observance of re-org protection for asset proofs. The file format now
> also uses an incremental hash function to reduce memory requirements
> when added a new transition to the end of the file.
>
> * Specification of the vPSBT protocol [1] which is the analogue of normal
> PSBTs for the TAP layer. The packet format specifies custom key/value
> pairs for the protocol describes an aggregate TAP transaction. After
> the
> packet is signed by all participants, it's "anchored" into a normal
> Bitcoin transaction by committing to the resulting output commitments
> and witnesses.
>
> We've also made significant advancements in our initial implementation [2],
> with many wallets, explorers, services, and businesses working with us to
> test and iterate on both the protocol and the implementation. We're
> actively
> working on our next major release, which will be a major milestone towards
> the eventual mainnet deployment of the protocol!
>
>
> -- Laolu
>
> [1]: https://lightning.engineering/posts/2023-06-14-virtual-psbt/
> [2]: https://github.com/lightninglabs/taproot-assets
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230907/5796b886/attachment.html>
Oddbean new post about login | logout