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: 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: