path: root/b1/cb948bda78fe2065c73768b05da88462c495e2

Return-Path: <johanth@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 070F9C002D;
 Mon,  7 Nov 2022 13:51:28 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id D59F0607C1;
 Mon,  7 Nov 2022 13:51:27 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D59F0607C1
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=iCvvh9X7
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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,
 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 oN6J3d44tZtP; Mon,  7 Nov 2022 13:51:25 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 39A0960648
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x1131.google.com (mail-yw1-x1131.google.com
 [IPv6:2607:f8b0:4864:20::1131])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 39A0960648;
 Mon,  7 Nov 2022 13:51:25 +0000 (UTC)
Received: by mail-yw1-x1131.google.com with SMTP id
 00721157ae682-369426664f9so104477297b3.12; 
 Mon, 07 Nov 2022 05:51:25 -0800 (PST)
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=KNkw+HEskkrwKU7VYg4LxMjZkdTNsZCBzI8nlDcUpns=;
 b=iCvvh9X7TZY+X639rLs1/Q6nhIWCygM2AOiOD2vSIykh7GRePeNOVWMwLnxRWF5lwM
 cJq/ULRxtvTuFBZBPP8lZeNIgOCWCs8nCOUvBqK8b8kpT5VHctFs1duRrFXYjK3sk9Fz
 RcwciK9Mzw8kX5po2G8kF7P1ju6Ri7ZTmGgRMj9wzxZmD3KAa0NrFUlz3b1Lun0RETNa
 8NW0QhW6Vn2qxiWGbxa5A6AjWAiHHy//WzYpW6SAOx/zcqObNAPDPQGf7uXWe9belp60
 pp0ODMj9+7sjVoDHN3VLGMznvwcFKrYbr0QGwoAJtjpptOgwnhP2wKzG46a3uj8qlPId
 WEnQ==
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=KNkw+HEskkrwKU7VYg4LxMjZkdTNsZCBzI8nlDcUpns=;
 b=OAxx1mLs1htItRW93+pkx08MNcDl64MoUOPb95TqZCHBpCh51EqBTazc94HWahlhZv
 J2mKcr9sFakGefHzqKmLnq1nL/oQEPCBR21Rn3gLrKFUFyx8m6/vLj4xTuGG5gneRQEr
 R1NLsPjFo3dt9ynSD1k6sC8KMu1TWVyL552Tp9eXDwwlzyEWNd2mhCaGescud4ZpNLff
 cCVkR4tYUFOoRAI8cCsT1O1STqrqweozBYFYK791u3cybhcKM9jLf8gR1gjJISQmUWD5
 WhW/UZST9/3FBVTrY6iBBYJbRGCaAkKX+1PzIv6WmIjzkojNr71ShojvYgMDY3WRLmck
 jRPA==
X-Gm-Message-State: ACrzQf1QDwGuXjNIwCMaHMM0nBBPSB0PJ55moMViMBQQhoFwqByQ4w7z
 CWqN9MQWoFG4SHoQt6PQSmIbSdMRVzz7YPGXMXY2DUlvT/1MKA==
X-Google-Smtp-Source: AMsMyM4LBnUA2CzVZaB08MX/wZdQYbeP5C8cn9BZzRQ1JBqnL/btiHkbMYnZ+/2MxCaZKFFCRtkpxQUvZdseVAXQFRs=
X-Received: by 2002:a0d:ca14:0:b0:369:5dfa:4d56 with SMTP id
 m20-20020a0dca14000000b003695dfa4d56mr47426530ywd.260.1667829083989; Mon, 07
 Nov 2022 05:51:23 -0800 (PST)
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>
 <CAO3Pvs9EeKu1p9egeeRZduvgX_Xf21rh0N8iRY9xo2m01sw_oA@mail.gmail.com>
In-Reply-To: <CAO3Pvs9EeKu1p9egeeRZduvgX_Xf21rh0N8iRY9xo2m01sw_oA@mail.gmail.com>
From: =?UTF-8?Q?Johan_Tor=C3=A5s_Halseth?= <johanth@gmail.com>
Date: Mon, 7 Nov 2022 14:51:12 +0100
Message-ID: <CAD3i26BkzBSRTqaLxArHJVuE+41SnCzP3JmLoAreF-Lazxgjww@mail.gmail.com>
To: Olaoluwa Osuntokun <laolu32@gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Mon, 07 Nov 2022 14:02:58 +0000
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: Mon, 07 Nov 2022 13:51:28 -0000

Hi Laolu,

Yeah, that is definitely the main downside, as Ruben also mentioned:
tokens are "burned" if they get sent to an already spent UTXO, and
there is no way to block those transfers.

And I do agree with your concern about losing the blockchain as the
main synchronization point, that seems indeed to be a prerequisite for
making the scheme safe in terms of re-orgs and asynchronicity.

I do think the scheme itself is sound though (maybe not off-chain, see
below): it prevents double spending and as long as the clients adhere
to the "rule" of not sending to a spent UTXO you'll be fine (if not
your tokens will be burned, the same way as if you don't satisfy the
Taro script when spending).

Thinking more about the examples you gave, I think you are right it
won't easily be compatible with LN channels though:
If you want to refill an existing channel with tokens, you need the
channel counterparties to start signing new commitments that include
spending the newly sent tokens. A problem arises however, if the
channel is force-closed with a pre-existing commitment from before the
token transfer took place. Since this commitment will be spending the
funding UTXO, but not the new tokens, the tokens will be burned. And
that seems to be harder to deal with (Eltoo style channels could be an
avenue to explore, if one could override the broadcasted commitment).

Tl;dr: I think you're right, the scheme is not compatible with LN.

- Johan


On Sat, Nov 5, 2022 at 1:36 AM Olaoluwa Osuntokun <laolu32@gmail.com> wrote:
>
> 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