diff --git a/blip-tap.md b/blip-tap.md index fe0be96..e32081d 100644 --- a/blip-tap.md +++ b/blip-tap.md @@ -1,5 +1,5 @@ ``` -bLIP: ???? +bLIP: 29 Title: Taproot Asset Channels Status: Active Author: Olaoluwa Osuntokun @@ -212,7 +212,8 @@ merged. When splitting an asset, in order to ensure that the supply of an asset is conserved (no inflation occurred) any resulting UTXOs created from the source UTXO are inserted into a special MS-SMT tree dubbed a `split_commitment`. A "root" asset is designated which holds the root hash of -the `split_commitment`. Any splits that were created from the root asset +the `split_commitment`. Any splits that were created from the root asset carry +a special merkle proof that proves that no assets were inflated. This design enables a verifier to easily verify that an asset's supply wasn't inflated by verifying that the `(asset_id, amt)` of the input asset is exactly @@ -538,8 +539,10 @@ The funding output for the TAP layer is effectively a direct mirror of the funding output on the Bitcoin layer, with a normal tapscript tweak used rather than a BIP 86 tweak. -The `tap_asset_proof` message sends all the fully singed asset TLV leafs ahead -of time, as +The `tap_asset_proof` message can omit the normal witness field for the TLVs. +Instead, only a challenge TLV needs to be sent to prove that the initiator can +actually move those assets. Unless otherwise specified, all asset TLVs as part +of this protocol will use encoding `v1`, also known as the segwit encoding. // TODO(roasbeef): partial reveal here? needed in any case to accept funding, but has similar issues to dual funding reveal, but constrained @@ -680,8 +683,8 @@ The `tap_to_local_script_root` is itself, a nested instance of the _existing_ The important derivation is the `script_key` of the TLV leaf in the asset tree, which is derived as: ``` -to_delay_script_root = tapscript_root([to_delay_script, revoke_script]) -tap_to_local_output_key = taproot_nums_point + tagged_hash("TapTweak", taproot_nums_point || to_delay_script_root) +tap_to_delay_script_root = tapscript_root([to_delay_script, revoke_script]) +tap_to_local_output_key = taproot_nums_point + tagged_hash("TapTweak", taproot_nums_point || tap_to_delay_script_root) ``` To derive the `tap_to_local_script_root`: @@ -901,10 +904,10 @@ mechanism to complete the route by bridging the TAP edge liquidity with the Bitcoin Backbone portion of the Lightning Network. For each logical payment to be accepted, the Edge Node and the Liquidity -Provider engage in Request-For-Quote (RFC) swap negotiation. Once a price has +Provider engage in Request-For-Quote (RFQ) swap negotiation. Once a price has been accepted, a final response is returned that uniquely identifies that specified price. The final quote is then identified by either a `tap_rfq_scid` -or a `tap_rfc_hash`. The former is laced in the first hop for an outgoing +or a `tap_rfq_hash`. The former is laced in the first hop for an outgoing payment with a TAP origin, and the latter placed within the normal onion payload for a last-mile hop into a TAP asset. @@ -951,6 +954,9 @@ bytes of the `rfq_id` and interpreting them as a 64-bit integer. The sender: + - MUST ensure that the `tap_rfq_scid` mapping of an `rfq_id` doesn't collide + with the `scid` of any active channels. + - MUST ensure that an `rfq_id` is never repeated for the lifetime of a connection - It is recommended that the value be generated using a CSPRNG. Otherwise, @@ -1017,7 +1023,7 @@ The sender: - MUST set `expiry_seconds` to the relative expiry time in the future that the quote will expire after which - - MUST set `rfg_sig` to be a BIP-340 schnorr signature over the serialized + - MUST set `rfq_sig` to be a BIP-340 schnorr signature over the serialized contents of the message without the `rfq_sig` serialized, using their node public key @@ -1060,7 +1066,7 @@ The recipient: #### First Hop TAP HTLC Onion Processing When sending a payment that uses an outbound TAP asset HTLC as it's origin, in -order for the payment succeed, the sender must place the negotiated `rfc_id` in +order for the payment succeed, the sender must place the negotiated `rfq_id` in the payload for the first hop (the liquidity provider): - type: 75253 @@ -1072,7 +1078,7 @@ HTLC has a TAP asset origin. In addition to the normal hop payload checks, the forwarding node MUST also verify that the conversion rate of the outgoing HTLC as specified in the onion -matches the `accepted_rate_tick` of the corresponding `tap_rfc_id`. +matches the `accepted_rate_tick` of the corresponding `tap_rfq_id`. When receiving an incoming onion TLV payload sourced from a TAP channel, the receiving node: @@ -1128,11 +1134,11 @@ receiver: `expiry_seconds` value - MUST reject the entire HTLC set if at anytime, the sum of HTLCs (the - `amt_to_forward` field) targetting `tap_rfc_scid` eceeds the negotiated + `amt_to_forward` field) targetting `tap_rfq_scid` eceeds the negotiated `asset_amt` field (volume for quote exhausted) - MUST extend a TAP HTLC with an `asset_id` corresponding to the accepted - `tap_rfc_scid` with an asset value of: `((amt_asset_incoming * + `tap_rfq_scid` with an asset value of: `((amt_asset_incoming * accepted_rate_tick) // msat_multiplier) / tick` * As an example: