From laolu32 at gmail.com  Wed Sep  6 19:27:48 2023
From: laolu32 at gmail.com (Olaoluwa Osuntokun)
Date: Wed, 6 Sep 2023 12:27:48 -0700
Subject: [Lightning-dev] blip-0029: Taproot Asset Protocol Channels
Message-ID: <CAO3Pvs_CJBk1VjzhbM-XnTuyQcfnF3i6szDW+W_KMtv06PdfPA@mail.gmail.com>

I'm excited to finally publish a draft bLIP describing how to map the
Taproot Asset Protocol onto the existing BOLT channel/invoice format,
specifically building on the active proposal for simple taproot channels!

https://github.com/lightning/blips/pull/29

This bLIP describes a variant on the "simple taproot channels" proposal
that also supports holding and transferring assets created by the Taproot
Assets Protocol. As Taproot Assets are built on top of the taproot itself,
from the PoV of the taproot channel format, Taproot Assets manifests
entirely as an extra tapscript sibling placed in the tapscript tee of
relevant outputs. A set of asset-specific balances (in the form of taproot
asset tree commitments) are maintained as an overlay layer on top of the
normal initiator+responder balances of Lightning channels. For channel
state transitions and eventual on-chain contract claims, in addition to
normal taproot witnesses, a set of taproot asset level witnesses are also
exchanged, encumbered by a nested iteration of the current Tapscript VM,
the Taproot Assets VM.

In order to facilitate multi-hop payments of the existing LN using Taproot
Assets edge liquidity, an RFQ (Request For Quote) last-mile negotiation
scheme is used to lock in an exchange rate for both incoming and outgoing
payments by liquidity providers. Tendered quotes `(asset_id, volume,
price)` are identified by a cryptographic hash and scid-like sequence
number, and ephemerally expire in order to reduce exchange rate risk. The
existing BOLT 11 invoice format is used verbatim, in a manner that allows
a receiver to accept an taproot asset without burdening the sender with up
to date knowledge of exchange rates. As no effective changes to the
invoice schemes are required, support for BOLT 12 invoices is readily
available.

Most importantly, the set up of the RFQ system and invoicing enables a
sender to be completely unaware of the nature of the asset the receiver is
requesting. All invoices are denominated in BTC as normal, with assets
crossed into BTC or the other way around at the edges. Similarly, the
sender can use any asset or BTC to pay any valid invoice. As the accepted
quotes expire, so do the invoices, just like normal invoices today. In the
future, the RFQ system can be extended to add prepayments, options, and
other techniques useful to bound exchange rate exposure.

The meat of the spec can really only be understood with a solid
understanding
of the set of BIPs [1]. However, I think most active LN devs will be able
to jump into the latter section that explains the new last-hop TLV
payload, the `rfq-scid` identifier, and how to carry out and receive
payments involving assets at either edge.

I look forward to any feedback or suggestions to further improve the
protocol. We're gearing up to release v0.3 of `tapd` [2], which is a major
milestone towards the mainnet release of the protocol. With lnd v0.17
(which includes an experimental version of taproot channels), and tapd
v0.3 in concert, we'll be able to finally realize the end to end version
of the protocol that enables users to send and receive assets at the
edges of the network, leveraging the Bitcoin Backbone of the network.

-- Laolu

[1]: https://github.com/bitcoin/bips/pull/1489
[2]: https://github.com/lightninglabs/taproot-assets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230906/8134e977/attachment.html>