path: root/78/303d2c691d697923d0d6fe03ef47b97598a72c

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&#39;t really been able to find a=
 precise technical explanation of the<br>&quot;utxo teleport&quot; scheme, =
but after thinking about your example use cases a<br>bit, I don&#39;t think=
 the scheme is actually sound. Consider that the scheme<br>attempts to targ=
et transmitting &quot;ownership&quot; 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 &quot;teleport&quot; 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&#39;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&#39;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&#39;t possible to send to something that won&#39;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&#39;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&#39;re all committed<br>to in the funding output when the channel i=
s created. However, let&#39;s say we<br>do teleporting instead: at which po=
int would we recognize the new asset<br>&quot;deposits&quot;? 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&#39;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--