path: root/2a/9f234758d4a654d02c38ddf95a4b6feca9b3d7

Return-Path: <zachgrw@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6F52CC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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: <CAO3Pvs_rPObfsPiPuDd9iWP677WQTsBGs0_ZuwVwHf3OTJcZzQ@mail.gmail.com>
In-Reply-To: <CAO3Pvs_rPObfsPiPuDd9iWP677WQTsBGs0_ZuwVwHf3OTJcZzQ@mail.gmail.com>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Thu, 7 Sep 2023 18:31:57 +0200
Message-ID: <CAJ4-pED=TOqiwRjHXTPqJ4uVGMHmKz0hRQXUhZbHZjCk4MXW7w@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
 Olaoluwa Osuntokun <laolu32@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"auto">Hi Laolu,</div><div dir=3D"auto"><br></div><div dir=3D"au=
to">Could you explain please how facilitating registering non-Bitcoin asset=
s on the Bitcoin blockchain is beneficial for the Bitcoin economy?</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">Thanks,</div><div dir=3D"auto">Z=
ac</div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Wed, 6 Sep 2023 at 21:02, Olaoluwa Osuntokun via bitcoin-dev &lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-styl=
e:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir=3D"lt=
r">After more than a year of tinkering, iterating, simplifying, and<br>impl=
ementing, I&#39;m excited to officially publish (and request BIP numbers<br=
>for) the Taproot Assets Protocol. Since the initial publishing we&#39;ve<b=
r>retained the same spec/document structure, with the addition of a new BIP=
<br>that describes the vPSBT format (which are PSBTs for the TAP layer). Ea=
ch<br>BIP now also contains a set of comprehensive test vectors (to be furt=
her<br>expanded over time.<div><br></div><div><a href=3D"https://github.com=
/bitcoin/bips/pull/1489" target=3D"_blank">https://github.com/bitcoin/bips/=
pull/1489</a></div><div><br></div><div>As the complete set of documents is =
large, we omit them from this email.=C2=A0<br><br>The breakdown of the BIPs=
 are as follows:<br><br>=C2=A0 * `bip-tap-mssmt`: describes the MS-SMT (Mer=
kle-Sum Sparse Merkle Tree)<br>=C2=A0 =C2=A0 data structure used to store a=
ssets and various proofs.<br><br>=C2=A0 * `bip-tap`: describes the Taproot =
Assets Protocol validation and state<br>=C2=A0 =C2=A0 transition rules.<br>=
<br>=C2=A0 * `bip-tap-addr`: describes the address format used to send and =
receive<br>=C2=A0 =C2=A0 assets.<br><br>=C2=A0 * `bip-tap-vm`: describes th=
e initial version of the off-chain TAP VM used<br>=C2=A0 =C2=A0 to lock and=
 unlock assets.<br><br>=C2=A0 * `bip-tap-vpsbt`: describes a vPSBT (virtual=
 PSBT) which is a series<br>=C2=A0 =C2=A0 custom types on top of the existi=
ng PSBT protocol to facilitate more<br>=C2=A0 =C2=A0 elaborate asset relate=
d transactions.<br><br>=C2=A0 * `bip-tap-proof-file`: describes the flat fi=
le format which is used to<br>=C2=A0 =C2=A0 prove and verify the provenance=
 of an asset<br><br>=C2=A0 * `bip-tap-universe`: describes the Universe ser=
ver construct, which is an<br>=C2=A0 =C2=A0 off-chain index into TAP data o=
n-chain, used for: proof distribution,<br>=C2=A0 =C2=A0 asset boostraping, =
and asset transaction archiving.<br><br>Some highlights of the additions/mo=
difications of the BIPs since the initial<br>drafts were published last yea=
r:<br><br>=C2=A0 * Test JSON vectors for each BIP document now included.<br=
><br>=C2=A0 * The Universe construct for initial verification of assets, di=
stributing<br>=C2=A0 =C2=A0 asset proofs, and transaction archiving is now =
further specified. A<br>=C2=A0 =C2=A0 naive and tree based syncing algorith=
m, along with a standardized<br>=C2=A0 =C2=A0 REST/gRPC interface are now i=
n place.<br><br>=C2=A0 * The asset group key structure (formerly known as a=
sset key families) has<br>=C2=A0 =C2=A0 been further developed. Group keys =
allow for the creation of assets that<br>=C2=A0 =C2=A0 support ongoing issu=
ance. A valid witness of a group key during the<br>=C2=A0 =C2=A0 minting pr=
ocess allows otherwise disparate assets to be considered<br>=C2=A0 =C2=A0 f=
ungible, and nested under the same sub-tree. A group key is itself just<br>=
=C2=A0 =C2=A0 a taproot output key. This enables complex issuance condition=
s such as:<br>=C2=A0 =C2=A0 multi-sig threshold, hash chain reveal, and any=
 other conditions<br>=C2=A0 =C2=A0 expressible by script (and eventually be=
yond!).<br><br>=C2=A0 * New versioning bytes across the protocol to ensure =
extensibility and<br>=C2=A0 =C2=A0 upgradability in a backwards compatible =
manner where possible. The asset<br>=C2=A0 =C2=A0 metadata format now has b=
een re-worked to only commit to a hash of the<br>=C2=A0 =C2=A0 serialized m=
eta data. Asset metadata can now also have structured data,<br>=C2=A0 =C2=
=A0 key-value or otherwise.<br><br>=C2=A0 * Observance of re-org protection=
 for asset proofs. The file format now<br>=C2=A0 =C2=A0 also uses an increm=
ental hash function to reduce memory requirements<br>=C2=A0 =C2=A0 when add=
ed a new transition to the end of the file.<br><br>=C2=A0 * Specification o=
f the vPSBT protocol [1] which is the analogue of normal<br>=C2=A0 =C2=A0 P=
SBTs for the TAP layer. The packet format specifies custom key/value<br>=C2=
=A0 =C2=A0 pairs for the protocol describes an aggregate TAP transaction. A=
fter the<br>=C2=A0 =C2=A0 packet is signed by all participants, it&#39;s &q=
uot;anchored&quot; into a normal<br>=C2=A0 =C2=A0 Bitcoin transaction by co=
mmitting to the resulting output commitments<br>=C2=A0 =C2=A0 and witnesses=
.<br><br>We&#39;ve also made significant advancements in our initial implem=
entation [2],<br>with many wallets, explorers, services, and businesses wor=
king with us to<br>test and iterate on both the protocol and the implementa=
tion. We&#39;re actively<br>working on our next major release, which will b=
e a major milestone towards<br>the eventual mainnet deployment of the proto=
col!<br><br><br>-- Laolu<br><br>[1]: <a href=3D"https://lightning.engineeri=
ng/posts/2023-06-14-virtual-psbt/" target=3D"_blank">https://lightning.engi=
neering/posts/2023-06-14-virtual-psbt/</a> <br>[2]: <a href=3D"https://gith=
ub.com/lightninglabs/taproot-assets" target=3D"_blank">https://github.com/l=
ightninglabs/taproot-assets</a><br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000b778280604c76664--