From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id DA0E2C0032 for ; Wed, 6 Sep 2023 19:01:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id BEA0C410E5 for ; Wed, 6 Sep 2023 19:01:34 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org BEA0C410E5 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=IcEeJfJ8 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsSu-R42NC9c for ; Wed, 6 Sep 2023 19:01:33 +0000 (UTC) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by smtp4.osuosl.org (Postfix) with ESMTPS id 240CA4089D for ; Wed, 6 Sep 2023 19:01:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 240CA4089D Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1c0d0bf18d7so1284365ad.0 for ; Wed, 06 Sep 2023 12:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694026892; x=1694631692; darn=lists.linuxfoundation.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=dq8wr5qh32dCCyTG6yf1OXrVWaKdKHYEOlwvXOfQjWc=; b=IcEeJfJ8Gaz/DiR23JP22W4NTsVXaqlqflolEPg93NeIR6QEUc18C4vPAv3KcjDfXw +eekqtkYw7/kykNof8qNjdp7ToDFzwl8CcXbdbUJsgevq6ml8rjGmm1UFWdZ2in/1r6q W0iHsqB96xBzMT2c6VVZHXTmX40La4PR+OhmBKt6DAXGeo1NXt9W7qTebfWA9jym69JY k5vZlaOlNyyczN6/VoGBSIv+sCLdamQSxnh+cnPm4U3sw7P6Df1Hyic8lqVuAq/VEZpw ZIQfZXkc/FpYIft45roYbfOXISmneP4rdnn2nRnWnpxJ3l+5OG6f4EwwQQGMVJewbe3D oXEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694026892; x=1694631692; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dq8wr5qh32dCCyTG6yf1OXrVWaKdKHYEOlwvXOfQjWc=; b=WXI2/P1UWAh9PmkWGvq3rBRtB/g19286d1rAuamvtNVIUTzky+idkhApAMYl3Gzg6l P65clB+s+zahAACBer6bT9I5CercY4owBlCpnd14K2s9YX7NPUuADhaBTgQwE4EKqBkk jjFGcAIg1godH9zNPLNtboTnagXwpuH3z94S9IQ+XcpBOMOb9P0+n07Y+lcEwOEo/6zj V3TKZhGvMPbWtFrd9bifiiOTcFt7wpsMlp8+fFXaZwQx24gtKDbofSDZ0FiB1gMf/aqj BdAZvUo0hJXH3AOrTzq8VSXPVlsKla85oqducNOPn+QIYZ0nmAkwFTRjVjZSlZVQEK6l tFxQ== X-Gm-Message-State: AOJu0YzA4gOvdwSwtvr6vljMUe50Dhqpri4sz2wv/B+cC70HY1uYArPX oiVGEMxOms39wYsqtyFUXLExjJYoSteuZ3UgWgVaEazHf1nSFA== X-Google-Smtp-Source: AGHT+IHJjoz1Dyth+kwiDRtzEEfP0zhbGIZWTyOTu5Ef8RnJNsHbeU2UxsWjPbqL0BOepDj7fUHYGaWTV2plQWy5Ui8= X-Received: by 2002:a17:90a:5ae6:b0:26b:5ba4:4948 with SMTP id n93-20020a17090a5ae600b0026b5ba44948mr13966103pji.12.1694026891958; Wed, 06 Sep 2023 12:01:31 -0700 (PDT) MIME-Version: 1.0 From: Olaoluwa Osuntokun Date: Wed, 6 Sep 2023 12:01:20 -0700 Message-ID: To: Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev Content-Type: multipart/alternative; boundary="00000000000022a10c0604b55f05" Subject: [bitcoin-dev] BIP-????: The Taproot Assets Protocol X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2023 19:01:35 -0000 --00000000000022a10c0604b55f05 Content-Type: text/plain; charset="UTF-8" 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 --00000000000022a10c0604b55f05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
After more than a year of tinkering, iterating, simplifyin= g, and
implementing, I'm excited to officially publish (and request = BIP numbers
for) the Taproot Assets Protocol. Since the initial publishi= ng we've
retained the same spec/document structure, with the additio= n 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 vecto= rs (to be further
expanded over time.


As the complete set of documents is larg= e, we omit them from this email.=C2=A0

The breakdown of the BIPs are= as follows:

=C2=A0 * `bip-tap-mssmt`: describes the MS-SMT (Merkle-= Sum Sparse Merkle Tree)
=C2=A0 =C2=A0 data structure used to store asset= s and various proofs.

=C2=A0 * `bip-tap`: describes the Taproot Asse= ts Protocol validation and state
=C2=A0 =C2=A0 transition rules.

= =C2=A0 * `bip-tap-addr`: describes the address format used to send and rece= ive
=C2=A0 =C2=A0 assets.

=C2=A0 * `bip-tap-vm`: describes the in= itial version of the off-chain TAP VM used
=C2=A0 =C2=A0 to lock and unl= ock assets.

=C2=A0 * `bip-tap-vpsbt`: describes a vPSBT (virtual PSB= T) which is a series
=C2=A0 =C2=A0 custom types on top of the existing P= SBT protocol to facilitate more
=C2=A0 =C2=A0 elaborate asset related tr= ansactions.

=C2=A0 * `bip-tap-proof-file`: describes the flat file f= ormat which is used to
=C2=A0 =C2=A0 prove and verify the provenance of = an asset

=C2=A0 * `bip-tap-universe`: describes the Universe server = construct, which is an
=C2=A0 =C2=A0 off-chain index into TAP data on-ch= ain, used for: proof distribution,
=C2=A0 =C2=A0 asset boostraping, and = asset transaction archiving.

Some highlights of the additions/modifi= cations of the BIPs since the initial
drafts were published last year:
=C2=A0 * Test JSON vectors for each BIP document now included.
=C2=A0 * The Universe construct for initial verification of assets, distri= buting
=C2=A0 =C2=A0 asset proofs, and transaction archiving is now furt= her specified. A
=C2=A0 =C2=A0 naive and tree based syncing algorithm, a= long with a standardized
=C2=A0 =C2=A0 REST/gRPC interface are now in pl= ace.

=C2=A0 * The asset group key structure (formerly known as asset= key families) has
=C2=A0 =C2=A0 been further developed. Group keys allo= w for the creation of assets that
=C2=A0 =C2=A0 support ongoing issuance= . A valid witness of a group key during the
=C2=A0 =C2=A0 minting proces= s allows otherwise disparate assets to be considered
=C2=A0 =C2=A0 fungi= ble, and nested under the same sub-tree. A group key is itself just
=C2= =A0 =C2=A0 a taproot output key. This enables complex issuance conditions s= uch as:
=C2=A0 =C2=A0 multi-sig threshold, hash chain reveal, and any ot= her conditions
=C2=A0 =C2=A0 expressible by script (and eventually beyon= d!).

=C2=A0 * New versioning bytes across the protocol to ensure ext= ensibility and
=C2=A0 =C2=A0 upgradability in a backwards compatible man= ner where possible. The asset
=C2=A0 =C2=A0 metadata format now has been= re-worked to only commit to a hash of the
=C2=A0 =C2=A0 serialized meta= data. Asset metadata can now also have structured data,
=C2=A0 =C2=A0 k= ey-value or otherwise.

=C2=A0 * Observance of re-org protection for = asset proofs. The file format now
=C2=A0 =C2=A0 also uses an incremental= hash function to reduce memory requirements
=C2=A0 =C2=A0 when added a = new transition to the end of the file.

=C2=A0 * Specification of the= vPSBT protocol [1] which is the analogue of normal
=C2=A0 =C2=A0 PSBTs = for the TAP layer. The packet format specifies custom key/value
=C2=A0 = =C2=A0 pairs for the protocol describes an aggregate TAP transaction. After= the
=C2=A0 =C2=A0 packet is signed by all participants, it's "= anchored" into a normal
=C2=A0 =C2=A0 Bitcoin transaction by commit= ting to the resulting output commitments
=C2=A0 =C2=A0 and witnesses.
We've also made significant advancements in our initial implementa= tion [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
--00000000000022a10c0604b55f05--