diff options
| author | Olaoluwa Osuntokun <laolu32@gmail.com> | 2022-11-04 17:35:53 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-11-05 00:36:11 +0000 |
| commit | 265f61de22171f389f34da47b7997e0504b3ad54 (patch) | |
| tree | da0a87881d1780ae68fcbef9879597589faccb64 | |
| parent | 63bda2f37e6f053875d84b2dbb039bc9ce60b41d (diff) | |
| download | pi-bitcoindev-265f61de22171f389f34da47b7997e0504b3ad54.tar.gz pi-bitcoindev-265f61de22171f389f34da47b7997e0504b3ad54.zip | |
Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset Representation Overlay
| -rw-r--r-- | 78/303d2c691d697923d0d6fe03ef47b97598a72c | 229 |
1 files changed, 229 insertions, 0 deletions
diff --git a/78/303d2c691d697923d0d6fe03ef47b97598a72c b/78/303d2c691d697923d0d6fe03ef47b97598a72c new file mode 100644 index 000000000..2dd6730a5 --- /dev/null +++ b/78/303d2c691d697923d0d6fe03ef47b97598a72c @@ -0,0 +1,229 @@ +Return-Path: <laolu32@gmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 20096C002D; + Sat, 5 Nov 2022 00:36:11 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id E813F82212; + Sat, 5 Nov 2022 00:36:10 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E813F82212 +Authentication-Results: smtp1.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20210112 header.b=S+XXG3rK +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 smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Ui6TxgF7QZS3; Sat, 5 Nov 2022 00:36:07 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1FA1381EDE +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com + [IPv6:2a00:1450:4864:20::434]) + by smtp1.osuosl.org (Postfix) with ESMTPS id 1FA1381EDE; + Sat, 5 Nov 2022 00:36:07 +0000 (UTC) +Received: by mail-wr1-x434.google.com with SMTP id cl5so9061737wrb.9; + Fri, 04 Nov 2022 17:36:06 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=cc:to:subject:message-id:date:from:in-reply-to:references + :mime-version:from:to:cc:subject:date:message-id:reply-to; + bh=8+G1xSdA0gSbXmJ2wLoXR8KuyUJkDAD+FujzyvUWScY=; + b=S+XXG3rKvYUzDBFhZo7Vpb3vqiconXKl7yyL38Zz7fXotzDifdLvrt0HZLP4f+qhb1 + Y4DmKxsMqe8SylCwxw+UAfG25Ebb3vxA2t+ZDRh31T1jb8HZa4fNTbnF7+7+BxGEGWnR + ZfOPf7e/hvafset2eOx5INU4cQZ8gDtp61zAyCI6lQOXsbqqccKOaXmuYN5W3AbwJY+P + QzC7cL37U+GFof8FUQtqZxET6GSSBuvQwY1Nea8J2i3Co9F+BBNW+2RmzZyMTTalidII + 50UoZAdFWML5KkRUzJdm/oGhUBcskhPOO26QGc3550rm3iH2EsQZsLWy4C/hSaA5FfOl + b+eA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=cc: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=8+G1xSdA0gSbXmJ2wLoXR8KuyUJkDAD+FujzyvUWScY=; + b=3Q/d0+9/BePxy7o0Ms1CBagewdSoUSRrJQXqtDrGSHWBFIDCOEE9gelnX5Ly0eihwU + OhLAXFbIP+rbeQA+O7wA8xAfJTdPNk4mvQdXyXoXNw2xAjsHH24G6Ede843bo+VLdJJt + Szlj15wa798z0WZ/0TEFjCaqZnirl12IUCydBg91wm7Hb62aZFRJ6PRQtwwaDUSPYlda + MkFA0wOeS9T3dN+nL7K0GyJM7X3ybiDBltULU5RMq/b6BGjQxiGNdRpjQiTc2PBz/68U + 27WMgw7SCflklFi/8k8pKOuioMdMSfmQyyOG4M41s5qQCJJNNN8yGwzbQAgfFRyfxjQB + OdFw== +X-Gm-Message-State: ACrzQf3ZQHpYXXG+WhA/aWMx5pEY0bNigXsZuJkPoFdNUKktgdW+zofU + wBGPZHdi7MW7bYVcz2O2GaZ3zhm7vpTmmNQnXgbUSFJEZXo= +X-Google-Smtp-Source: AMsMyM4wK1YuDot3Dmoxvnc0PZvsKOxn2FJQ8hckhz6Wk+7RtBiYjJUK3r9/acduPjKjXsWXjEAY7DUP4f99vpfE/7I= +X-Received: by 2002:a05:6000:4004:b0:236:d252:ee4b with SMTP id + cy4-20020a056000400400b00236d252ee4bmr18058683wrb.677.1667608565137; Fri, 04 + Nov 2022 17:36:05 -0700 (PDT) +MIME-Version: 1.0 +References: <CAO3Pvs_pkYAYsrAEtv3KuJevXQHBLZQ-ihjP4Ur_A1NjJRA+Lw@mail.gmail.com> + <CAPv7TjYTjvSV7UFgOwif6tFj3jVxDfJdW-p_cyPoAGGWKQbwRQ@mail.gmail.com> + <CAO3Pvs_-igT37fcD29=ATSRX7dW5mGKrLGrXp=iJjaN_t3NGww@mail.gmail.com> + <CAPv7TjZjZU2bYvUrt-BEx80xKF=BHBbrYWigHB+=yY+YfZX9Yg@mail.gmail.com> + <CAD3i26AOmfHz1aOJGwzixQuwMtoo=v5qbveZUasbkzL1sPJWLw@mail.gmail.com> +In-Reply-To: <CAD3i26AOmfHz1aOJGwzixQuwMtoo=v5qbveZUasbkzL1sPJWLw@mail.gmail.com> +From: Olaoluwa Osuntokun <laolu32@gmail.com> +Date: Fri, 4 Nov 2022 17:35:53 -0700 +Message-ID: <CAO3Pvs9EeKu1p9egeeRZduvgX_Xf21rh0N8iRY9xo2m01sw_oA@mail.gmail.com> +To: =?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?= <johanth@gmail.com> +Content-Type: multipart/alternative; boundary="00000000000026460f05ecae60ca" +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + lightning-dev <lightning-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] [Lightning-dev] Taro: A Taproot Asset + Representation Overlay +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: Sat, 05 Nov 2022 00:36:11 -0000 + +--00000000000026460f05ecae60ca +Content-Type: text/plain; charset="UTF-8" + +Hi Johan, + +I haven't really been able to find a precise technical explanation of the +"utxo teleport" scheme, but after thinking about your example use cases a +bit, I don't think the scheme is actually sound. Consider that the scheme +attempts to target transmitting "ownership" to a UTXO. However, by the time +that transaction hits the chain, the UTXO may no longer exist. At that +point, what happens to the asset? Is it burned? Can you retry it again? Does +it go back to the sender? + +As a concrete example, imagine I have a channel open, and give you an +address to "teleport" some additional assets to it. You take that addr, then +make a transaction to commit to the transfer. However, the block before you +commit to the transfer, my channel closes for w/e reason. As a result, when +the transaction committing to the UTXO (blinded or not), hits the chain, the +UTXO no longer exists. Alternatively, imagine the things happen in the +expected order, but then a re-org occurs, and my channel close is mined in a +block before the transfer. Ultimately, as a normal Bitcoin transaction isn't +used as a serialization point, the scheme seems to lack a necessary total +ordering to ensure safety. + +If we look at Taro's state transition model in contrast, everything is fully +bound to a single synchronization point: a normal Bitcoin transaction with +inputs consumed and outputs created. All transfers, just like Bitcoin +transactions, end up consuming assets from the set of inputs, and +re-creating them with a different distribution with the set of outputs. As a +result, Taro transfers inherit the same re-org safety traits as regular +Bitcoin transactions. It also isn't possible to send to something that won't +ultimately exist, as sends create new outputs just like Bitcoin +transactions. + +Taro's state transition model also means anything you can do today with +Bitcoin/LN also apply. As an example, it would be possible for you to +withdrawn from your exchange into a Loop In address (on chain to off chain +swap), and have everything work as expected, with you topping off your +channel. Stuff like splicing, and other interactive transaction construction +schemes (atomic swaps, MIMO swaps, on chain auctions, etc) also just work. + +Ignoring the ordering issue I mentioned above, I don't think this is a great +model for anchoring assets in channels either. With Taro, when you make the +channel, you know how many assets are committed since they're all committed +to in the funding output when the channel is created. However, let's say we +do teleporting instead: at which point would we recognize the new asset +"deposits"? What if we close before a pending deposits confirms, how can one +regain those funds? Once again you lose the serialization of events/actions +the blockchain provides. I think you'd also run into similar issues when you +start to think about how these would even be advertised on a hypothetical +gossip network. + +I think one other drawback of the teleport model iiuc is that: it either +requires an OP_RETURN, or additional out of band synchronization to complete +the transfer. Since it needs to commit to w/e hash description of the +teleport, it either needs to use an OP_RETURN (so the receiver can see the +on chain action), or the sender needs to contact the receiver to initiate +the resolution of the transfer (details committed to in a change addr or +w/e). + +With Taro, sending to an address creates an on-chain taproot output just +like sending to a P2TR address. The creation of the output directly creates +the new asset anchor/output as well, which allows the receiver to look for +that address on chain just like a normal on chain transaction. To 3rd party +observers, it just looks like a normal P2TR transfer. In order to finalize +the receipt of the asset, the receiver needs to obtain the relevant +provenance proofs, which can be obtained from a multi-verse gRPC/HTTP +service keyed by the input outpoint and output index. In short, the send +process is fully async, with the sender and receiver using the blockchain +itself as a synchronization point like a normal Bitcoin wallet. + +-- Laolu + +--00000000000026460f05ecae60ca +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi Johan, <br><br>I haven't really been able to find a= + precise technical explanation of the<br>"utxo teleport" scheme, = +but after thinking about your example use cases a<br>bit, I don't think= + the scheme is actually sound. Consider that the scheme<br>attempts to targ= +et transmitting "ownership" to a UTXO. However, by the time<br>th= +at transaction hits the chain, the UTXO may no longer exist. At that<br>poi= +nt, what happens to the asset? Is it burned? Can you retry it again? Does<b= +r>it go back to the sender?<br><br>As a concrete example, imagine I have a = +channel open, and give you an<br>address to "teleport" some addit= +ional assets to it. You take that addr, then<br>make a transaction to commi= +t to the transfer. However, the block before you<br>commit to the transfer,= + my channel closes for w/e reason. As a result, when<br>the transaction com= +mitting to the UTXO (blinded or not), hits the chain, the<br>UTXO no longer= + exists. Alternatively, imagine the things happen in the<br>expected order,= + but then a re-org occurs, and my channel close is mined in a<br>block befo= +re the transfer. Ultimately, as a normal Bitcoin transaction isn't<br>u= +sed as a serialization point, the scheme seems to lack a necessary total<br= +>ordering to ensure safety.<br><br>If we look at Taro's state transitio= +n model in contrast, everything is fully<br>bound to a single synchronizati= +on point: a normal Bitcoin transaction with<br>inputs consumed and outputs = +created. All transfers, just like Bitcoin<br>transactions, end up consuming= + assets from the set of inputs, and<br>re-creating them with a different di= +stribution with the set of outputs. As a<br>result, Taro transfers inherit = +the same re-org safety traits as regular<br>Bitcoin transactions. It also i= +sn't possible to send to something that won't<br>ultimately exist, = +as sends create new outputs just like Bitcoin<br>transactions.<br><br>Taro&= +#39;s state transition model also means anything you can do today with<br>B= +itcoin/LN also apply. As an example, it would be possible for you to<br>wit= +hdrawn from your exchange into a Loop In address (on chain to off chain<br>= +swap), and have everything work as expected, with you topping off your<br>c= +hannel. Stuff like splicing, and other interactive transaction construction= +<br>schemes (atomic swaps, MIMO swaps, on chain auctions, etc) also just wo= +rk.<br><br>Ignoring the ordering issue I mentioned above, I don't think= + this is a great<br>model for anchoring assets in channels either. With Tar= +o, when you make the<br>channel, you know how many assets are committed sin= +ce they're all committed<br>to in the funding output when the channel i= +s created. However, let's say we<br>do teleporting instead: at which po= +int would we recognize the new asset<br>"deposits"? What if we cl= +ose before a pending deposits confirms, how can one<br>regain those funds? = +Once again you lose the serialization of events/actions<br>the blockchain p= +rovides. I think you'd also run into similar issues when you<br>start t= +o think about how these would even be advertised on a hypothetical<br>gossi= +p network.<br><br>I think one other drawback of the teleport model iiuc is = +that: it either<br>requires an OP_RETURN, or additional out of band synchro= +nization to complete<br>the transfer. Since it needs to commit to w/e hash = +description of the<br>teleport, it either needs to use an OP_RETURN (so the= + receiver can see the<br>on chain action), or the sender needs to contact t= +he receiver to initiate<br>the resolution of the transfer (details committe= +d to in a change addr or<br>w/e). <br><br>With Taro, sending to an address = +creates an on-chain taproot output just<br>like sending to a P2TR address. = +The creation of the output directly creates<br>the new asset anchor/output = +as well, which allows the receiver to look for<br>that address on chain jus= +t like a normal on chain transaction. To 3rd party<br>observers, it just lo= +oks like a normal P2TR transfer. In order to finalize<br>the receipt of the= + asset, the receiver needs to obtain the relevant<br>provenance proofs, whi= +ch can be obtained from a multi-verse gRPC/HTTP<br>service keyed by the inp= +ut outpoint and output index. In short, the send<br>process is fully async,= + with the sender and receiver using the blockchain<br>itself as a synchroni= +zation point like a normal Bitcoin wallet.<br><br>-- Laolu<br></div> + +--00000000000026460f05ecae60ca-- + |