Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6F52CC0032 for ; Thu, 7 Sep 2023 16:32:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 437B761257 for ; Thu, 7 Sep 2023 16:32:11 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 437B761257 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=YxCPX++E X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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 smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyZFIq6Dp6mD for ; Thu, 7 Sep 2023 16:32:09 +0000 (UTC) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by smtp3.osuosl.org (Postfix) with ESMTPS id B942360B1F for ; Thu, 7 Sep 2023 16:32:09 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B942360B1F Received: by mail-qk1-x733.google.com with SMTP id af79cd13be357-770627a7316so70040785a.0 for ; Thu, 07 Sep 2023 09:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1694104328; x=1694709128; darn=lists.linuxfoundation.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=64A4vxo2GI4ozjjj3AsDQfVWUbMBUw7mO5GSCl0s6Gg=; b=YxCPX++EhEE8g/0JjvfK1miQzpl9TTvgR1TvIW0ZL6BgODzYQeDjzGE8DrbHIkoTpg tyUIHPadcQi6vyrNdwltsmAsYH7wIqvb4bpVEGbxDvYX/lMJ7kvZXcbPn5Q0tZgU9yky lCjCzUvtPq0vCUOCfrsXgzU5VahrnIu55NEtovSoYTH8ohKkGLPq+Wxh4juBF8sKmqwY isiFVhq2w81X8DrF2xYc9E1aAfZntcul6e+KV56UZ2eRHdWTsx3Y2OAQ3JOMVvIkHYe3 zkGcIIXtMh6cdRbfDwkp2Oa6nrm9wxPx1GxGCoeLW6G9kmcDD9HqvgicXEJih6bNmY2K oI6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694104328; x=1694709128; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=64A4vxo2GI4ozjjj3AsDQfVWUbMBUw7mO5GSCl0s6Gg=; b=Lf/sdg5BcY/d+8I5DYtgPRKpANn2Y1piBVGVGTarzss3WjJaIlUKtCsrw5XVTl3EKA niZDi63XFO9UGJxoK29hDCCKQH5EKNA9iqi+UcvoQqGT7xIZC7WiR/OmHeCOT4I5rJOR RKWQN87hZZgWDfYeS+4fs/6CvPr8sv9HTH0z1rWP/4yE8gKh+up0i4nzD3smsf9yki5w mrsbrQ3xnEwLQdstGwI7ekj2j2OdVqw67e+KgLZ7pLAQRaHmwLOkodVK+EH5UODlrg6+ DlJtnIHQeLi7spet4sHPg+lkwjJS0r6U1VrQC1OSUeW6pI8h19MtpOqvEpbIY75tA588 JL5Q== X-Gm-Message-State: AOJu0YxfEhLVqq18tz9fMc+acYMpfJxnE8LnrxMmviFI1R9/BMP8lCjO w5u49YyR0u12vUiqTIusf0ZXLgSec1lT6N2ll0SxNe1P X-Google-Smtp-Source: AGHT+IEC/ipUMAAMY4JvXiu0L9w1iP7l8pDcB6iGv3ZKcPX4f+HmDNjur1znMmnHYI/tQZv3T18V4wclfmRoKrn+/qM= X-Received: by 2002:a05:620a:91d:b0:76c:a9a1:a318 with SMTP id v29-20020a05620a091d00b0076ca9a1a318mr18553qkv.6.1694104328565; Thu, 07 Sep 2023 09:32:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Zac Greenwood Date: Thu, 7 Sep 2023 18:31:57 +0200 Message-ID: To: Bitcoin Protocol Discussion , Olaoluwa Osuntokun Content-Type: multipart/alternative; boundary="000000000000b778280604c76664" X-Mailman-Approved-At: Thu, 07 Sep 2023 23:31:07 +0000 Subject: Re: [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: Thu, 07 Sep 2023 16:32:11 -0000 --000000000000b778280604c76664 Content-Type: text/plain; charset="UTF-8" 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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000b778280604c76664 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Laolu,

Could you explain please how facilitating registering non-Bitcoin asset= s on the Bitcoin blockchain is beneficial for the Bitcoin economy?

Thanks,
Z= ac

On Wed, 6 Sep 2023 at 21:02, Olaoluwa Osuntokun via bitcoin-dev <= bitcoin-dev@lists.= linuxfoundation.org> wrote:
After more than a year of tinkering, iterating, simplifying, and
impl= ementing, I'm excited to officially publish (and request BIP numbersfor) the Taproot Assets Protocol. Since the initial publishing we'veretained the same spec/document structure, with the addition of a new BIP=
that describes the vPSBT format (which are PSBTs for the TAP layer). Ea= ch
BIP now also contains a set of comprehensive test vectors (to be furt= her
expanded over time.


As the complete set of documents is = large, 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 (Mer= kle-Sum Sparse Merkle Tree)
=C2=A0 =C2=A0 data structure used to store a= ssets and various proofs.

=C2=A0 * `bip-tap`: describes the Taproot = Assets Protocol validation and state
=C2=A0 =C2=A0 transition rules.
=
=C2=A0 * `bip-tap-addr`: describes the address format used to send and = receive
=C2=A0 =C2=A0 assets.

=C2=A0 * `bip-tap-vm`: describes th= e initial version of the off-chain TAP VM used
=C2=A0 =C2=A0 to lock and= unlock assets.

=C2=A0 * `bip-tap-vpsbt`: describes a vPSBT (virtual= PSBT) which is a series
=C2=A0 =C2=A0 custom types on top of the existi= ng PSBT protocol to facilitate more
=C2=A0 =C2=A0 elaborate asset relate= d transactions.

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

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

Some highlights of the additions/mo= difications of the BIPs since the initial
drafts were published last yea= r:

=C2=A0 * Test JSON vectors for each BIP document now included.
=C2=A0 * The Universe construct for initial verification of assets, di= stributing
=C2=A0 =C2=A0 asset proofs, and transaction archiving is now = further specified. A
=C2=A0 =C2=A0 naive and tree based syncing algorith= m, along with a standardized
=C2=A0 =C2=A0 REST/gRPC interface are now i= n place.

=C2=A0 * The asset group key structure (formerly known as a= sset key families) has
=C2=A0 =C2=A0 been further developed. Group keys = allow for the creation of assets that
=C2=A0 =C2=A0 support ongoing issu= ance. A valid witness of a group key during the
=C2=A0 =C2=A0 minting pr= ocess allows otherwise disparate assets to be considered
=C2=A0 =C2=A0 f= ungible, 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 condition= s such as:
=C2=A0 =C2=A0 multi-sig threshold, hash chain reveal, and any= other conditions
=C2=A0 =C2=A0 expressible by script (and eventually be= yond!).

=C2=A0 * New versioning bytes across the protocol to ensure = extensibility and
=C2=A0 =C2=A0 upgradability in a backwards compatible = manner where possible. The asset
=C2=A0 =C2=A0 metadata format now has b= een re-worked to only commit to a hash of the
=C2=A0 =C2=A0 serialized m= eta data. Asset metadata can now also have structured data,
=C2=A0 =C2= =A0 key-value or otherwise.

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

=C2=A0 * Specification o= f the vPSBT protocol [1] which is the analogue of normal
=C2=A0 =C2=A0 P= SBTs for the TAP layer. The packet format specifies custom key/value
=C2= =A0 =C2=A0 pairs for the protocol describes an aggregate TAP transaction. A= fter the
=C2=A0 =C2=A0 packet is signed by all participants, it's &q= uot;anchored" into a normal
=C2=A0 =C2=A0 Bitcoin transaction by co= mmitting to the resulting output commitments
=C2=A0 =C2=A0 and witnesses= .

We've also made significant advancements in our initial implem= entation [2],
with many wallets, explorers, services, and businesses wor= king with us to
test and iterate on both the protocol and the implementa= tion. We're actively
working on our next major release, which will b= e a major milestone towards
the eventual mainnet deployment of the proto= col!


-- Laolu

[1]: https://lightning.engi= neering/posts/2023-06-14-virtual-psbt/
[2]: https://github.com/l= ightninglabs/taproot-assets
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000b778280604c76664--