|
| 1 | +<pre> |
| 2 | + BIP: ??? |
| 3 | + Layer: Applications |
| 4 | + Title: Taproot Asset On Chain Addresses |
| 5 | + Author: Olaoluwa Osuntokun < [email protected]> |
| 6 | + Comments-Summary: No comments yet. |
| 7 | + Comments-URI: https://git |
| 8 | + Status: Draft |
| 9 | + Type: Standards Track |
| 10 | + Created: 2021-12-10 |
| 11 | + License: BSD-2-Clause |
| 12 | +</pre> |
| 13 | + |
| 14 | +==Abstract== |
| 15 | + |
| 16 | +This document describes a way to map a single-asset Taproot Asset send to a |
| 17 | +familiar <code>bech32m</code> address, as well as a way to map that address into |
| 18 | +a valid Taproot Asset script tree that can be included in a broadcast |
| 19 | +transaction to complete a transfer. |
| 20 | +Once the transaction has been broadcast, the receiver can use the |
| 21 | +previous outpoint of the confirmed transaction to lookup the complete asset |
| 22 | +proof in their chosen Universe. |
| 23 | + |
| 24 | +==Copyright== |
| 25 | + |
| 26 | +This document is licensed under the 2-clause BSD license. |
| 27 | + |
| 28 | +==Motivation== |
| 29 | + |
| 30 | +The Taproot Asset protocol needs an easy way to allow users to send each other |
| 31 | +assets on-chain, without requiring several rounds of interaction to exchange and |
| 32 | +validate proofs. By using the existing <code>bech32m</code> address |
| 33 | +serialization standard, such addresses look distinct, while also looking |
| 34 | +familiar enough based on the character set encoding. The described address |
| 35 | +format also addresses a number of possible foot guns, by making it impossible |
| 36 | +to send the wrong asset (based on an address) amongst other protections. |
| 37 | + |
| 38 | +==Specification== |
| 39 | + |
| 40 | +A Taproot Asset is uniquely defined by its <code>asset_genesis</code> as well as |
| 41 | +the <code>asset_script_key</code> that serves as a predicate that must be |
| 42 | +satisfied for transfers. These values, along with an internal Taproot key used |
| 43 | +when creating the Bitcoin output that holds the Taproot Asset, are encoded into |
| 44 | +a single address. |
| 45 | + |
| 46 | +===Encoding an Address=== |
| 47 | + |
| 48 | +Let the human readable prefix (as specified by BIP 173) be: |
| 49 | + |
| 50 | +* <code>tapbc</code> for mainnet |
| 51 | +* <code>taptb</code> for testnet |
| 52 | +* <code>taprt</code> for regtest |
| 53 | +* <code>taptb</code> for the public signet |
| 54 | +* <code>tapsb</code> for simnet |
| 55 | +
|
| 56 | +We refer to this value as the <code>taproot_asset_hrp</code> |
| 57 | + |
| 58 | +Given the 32-byte <code>asset_id</code>, 33-byte compressed |
| 59 | +<code>asset_script_key</code>, and 33-byte compressed internal public |
| 60 | +key, 8-byte amount to send, an address is encoded as: |
| 61 | +* <code>bech32m(hrp=taproot_asset_hrp, addr_tlv_payload)</code> |
| 62 | +
|
| 63 | +where <code>addr_tlv_payload</code> is a TLV payload composed of the following |
| 64 | +types: |
| 65 | +* type: 0 (<code>taproot_asset_version</code>) |
| 66 | +** value: |
| 67 | +*** [<code>u8</code>:<code>version</code>] |
| 68 | +* type: 2 (<code>asset_id</code>) |
| 69 | +** value: |
| 70 | +*** [<code>32*byte</code>:<code>asset_id</code>] |
| 71 | +* type: 3 (<code>asset_key_family</code>) |
| 72 | +** value: |
| 73 | +*** [<code>33*byte</code>:<code>family_key</code>] |
| 74 | +* type: 4 (<code>asset_script_key</code>) |
| 75 | +** value: |
| 76 | +*** [<code>33*byte</code>:<code>script_key</code>] |
| 77 | +* type: 6 (<code>internal_key</code>) |
| 78 | +** value: |
| 79 | +*** [<code>33*byte</code>:<code>taproot_internal_key</code>] |
| 80 | +* type: 7 (<code>taproot_sibling_preimage</code>) |
| 81 | +** value: |
| 82 | +*** [<code>...*byte</code>:<code>tapscript_preimage</code>] |
| 83 | +* type: 8 (<code>amt</code>) |
| 84 | +** value: |
| 85 | +*** [<code>BigSize</code>:<code>amt_to_send</code>] |
| 86 | +* type: 10 (<code>proof_courier_addr</code>) |
| 87 | +** value: |
| 88 | +*** [<code>...*byte</code>:<code>proof_courier_addr</code>] |
| 89 | +
|
| 90 | +Inspired by Lightning's BOLT specification, we adopt the "it's OK to be odd" |
| 91 | +semantics here as well. This enables receivers to specify to the caller certain |
| 92 | +information that MUST be known in order to properly complete a transfer. |
| 93 | + |
| 94 | +The only odd keys specified in the current version are the |
| 95 | +<code>asset_key_family</code> type and the <code>asset_type</code> field. The |
| 96 | +<code>asset_key_family</code> field isn't always needed for assets that don't |
| 97 | +allow for continual re-issuance. Similarly, if the <code>asset_type</code> |
| 98 | +field isn't specified, then one can assume a normal asset is being sent. |
| 99 | + |
| 100 | +The <code>proof_courier_addr</code> is a mandatory URI (RFC 3986) that indicates |
| 101 | +what proof courier to use when sending the proofs from the sender to the |
| 102 | +recipient. The scheme (protocol) indicates the type of courier transport to use, |
| 103 | +current valid values are <code>hashmail://</code> for Hashmail based couriers |
| 104 | +and <code>universerpc://</code> for gRPC based transfer via a universe server. |
| 105 | + |
| 106 | +===Decoding and Sending To An Address=== |
| 107 | + |
| 108 | +Given a valid Taproot Asset address, decompose the contents into the referenced |
| 109 | +<code>asset_id</code>, <code>asset_script_key</code>, and |
| 110 | +<code>internal_key</code>. Look up the full <code>asset_genesis</code> with the |
| 111 | +<code>asset_id</code> in the appropriate Universe. |
| 112 | + |
| 113 | +Construct a new blank Taproot Asset leaf according to the default |
| 114 | +[[./bip-tap.mediawiki#asset-leaf-format|Asset Leaf Format]] with the following |
| 115 | +values being set explicitly (and all other values being their default/zero |
| 116 | +values): |
| 117 | +* <code>taproot_asset_version</code>: <code>0</code> |
| 118 | +* <code>asset_genesis</code>: <code>asset_genesis</code> |
| 119 | +* <code>amt</code>: <code>amt_to_send</code> |
| 120 | +* <code>asset_script_version</code>: <code>0</code> |
| 121 | +* <code>asset_script_key</code>: <code>asset_script_key</code> |
| 122 | +* <code>asset_key_family</code>: <code>asset_key_family</code> |
| 123 | +
|
| 124 | +Create a valid tapscript root, using leaf version <code>0x0c</code> with the |
| 125 | +sole leaf being the serialized TLV blob specified above. |
| 126 | + |
| 127 | +Create the top-level taproot public key script, as a segwit v1 witness |
| 128 | +program, as specified in BIP 341, using the included key as the internal key. |
| 129 | + |
| 130 | +With the target taproot public key script constructed, the asset is sent to the |
| 131 | +receiver with the execution of the following steps: |
| 132 | +# Construct a valid transaction that spends an input that holds the referenced <code>asset_id</code> and ''exactly'' <code>amt</code> units of the asset. |
| 133 | +# Create a new Taproot Asset output commitment based on the input commitment (this will be the change output), that now only commits to <code>S-A</code> units of <code>asset_id</code>, where <code>S</code> is the input amount, and <code>A</code> is the amount specified in the encoded Taproot Asset address. |
| 134 | +## This new leaf MUST have a <code>split_commitment</code> specified that commits to the position (keyed by <code>sha256(output_index || asset_id || asset_script_key)</code> within the transaction of the newly created asset leaf for the receiver. This split commitment is omitted by the sender when serializing the leaf for inclusion in the asset tree, otherwise the tree wouldn't be predictable on the receiver side. This has a corresponding rule in the [[./bip-tap-vm.mediawiki|bip-tap-vm]] during the input mapping of the inclusion proof validation. |
| 135 | +## Add an additional output that sends a de minimis (in practice this MUST be above dust) amount to the top-level taproot public key computed earlier. |
| 136 | +## Broadcast and sign the transaction, submitting the resulting Taproot Asset state transition proof to a Universe of choice, also known by the receiver. |
| 137 | +# Post the resulting state transition proof to the specified Universe. The submitted proof ''must'' contain the optional auxiliary value of the full <code>split_commitment</code> the receiver requires to spend the asset. |
| 138 | +
|
| 139 | +===Non-interactive full value send=== |
| 140 | + |
| 141 | +Sending assets to an address is inherently a non-interactive process as there is |
| 142 | +no active communication between the sender and recipient other than the exchange |
| 143 | +of the address in the first place. |
| 144 | +Because of the above mentioned requirement that an asset leaf created to send to |
| 145 | +an address MUST have a <code>split_commitment</code>, a special case exists if |
| 146 | +there is no change going back to the sender (an asset output is fully consumed |
| 147 | +by the transfer to an address): A special ''tombstone'' output with a value of |
| 148 | +0 must be created for the split root asset (the <code>root_asset</code> of the |
| 149 | +split) that holds the transfer witness. The <code>script_key</code> of the |
| 150 | +split root asset output should be the well-known NUMS point (using the string |
| 151 | +"taproot-assets" and the traditional "hash and increment" approach to generating |
| 152 | +the point) to prove the output cannot be spent further. Such a tombstone output |
| 153 | +can then be pruned from the tree when the UTXO is spent further. |
| 154 | +More details about interactive and non-interactive sends and tombstone outputs |
| 155 | +can be found in the [[./bip-tap-psbt.mediawiki|bip-tap-psbt]]. |
| 156 | + |
| 157 | +===Spending The Received Asset=== |
| 158 | + |
| 159 | +In order to spend (or simply confirm receipt) of the received asset, the |
| 160 | +receiver should: |
| 161 | +# Re-derive the taproot public key script created above that sends to their specified Taproot Asset leaf. |
| 162 | +# Wait for a transaction creating the output to be confirmed in the blockchain. |
| 163 | +## In practice this may be via light client protocols such as BIP 157/158, or simply a full node with an address index, or import public key. |
| 164 | +# For each previous outpoint referenced in the transaction: |
| 165 | +## Look up the previous outpoint as a key into the chosen canonical Universe/Multiverse. |
| 166 | +### If the key is found, verify the inclusion proof of the value (as described in [[./bip-tap-proof-file.mediawiki|bip-tap-proof-file]]), and extract the <code>split_commitment</code> inclusion proof for the output. |
| 167 | +# Walk the Universe tree backwards in time to incrementally construct the full provenance proof needed to spend the asset. |
| 168 | +
|
| 169 | +==Test Vectors== |
| 170 | + |
| 171 | +Test vectors for [[Encoding an Address]] can be found here: |
| 172 | +* [[bip-tap-addr/address_tlv_encoding_generated.json|Address TLV encoding test vectors]] |
| 173 | +* [[bip-tap-addr/address_tlv_encoding_error_cases.json|Address TLV encoding error test vectors]] |
| 174 | +
|
| 175 | +The test vectors are automatically generated by |
| 176 | +[https://github.com/lightninglabs/taproot-assets/tree/main/address unit tests in |
| 177 | +the Taproot Assets GitHub repository]. |
| 178 | + |
| 179 | +==Reference Implementation== |
| 180 | + |
| 181 | +github.com/lightninglabs/taproot-assets/tree/main/address |
| 182 | + |
0 commit comments