techmedia-think.hatenablog.com
↑のアセットの新規発行に続いて、アセットを送付しようと思ったけど、その前にアセットを受け取る際に必要になるTaroのオンチェーンアドレス仕様について見ておく。
Taroアドレス
Taroのアセットを受け取る際のアドレスは既存のBitcoinアドレスではなく、その仕様は↓のBIPドラフトに定義されている。
https://github.com/Roasbeef/bips/blob/bip-taro/bip-taro-addr.mediawiki
アドレスはエンコード仕様にTaprootと同じbech32mを採用しており、bech32mのhuman-readable parts（HRP）は
- mainnetが
tarobc - testnet/signetが
tarotb - regtestが
tarort
で（BIPドラフトではtaroとtarotと記載されてるけど、tarodのα版では↑のように定義されてる）、データ部は、以下のTLVデータで構成される。
| タイプ | 定義 | 値 |
|---|---|---|
| 0 | taro_version | Taroのバージョン。現在は0。 |
| 2 | asset_id | 受け取るアセットのアセットID。※ ただα版の実装ではIDではなくアセットジェネシスになってる。 |
| 3 | asset_key_family | アセットファミリーキー。異なるアセットIDのアセットを関連付けるために使用する鍵。ノーマルタイプのアセットを追加発行する際に、発行済のアセットと追加発行したアセットでIDが異なるので、それを紐付けるために利用。 |
| 4 | asset_script_key | アセットを受け取る公開鍵 |
| 6 | internal_key | アセットを受け取るトランザクションアウトプット（Taprootアウトプット）で使用するTaprootの内部鍵（公開鍵） |
| 8 | amt | 受け取るアセットの量 |
| 9 | asset_type | アセットタイプ（省略時は0=ノーマル）Type:2がジェネシスになるのであれば必要ないので無くなるものと思われる。 |
タイプが厳密に連番じゃないのは、ライトニングの機能ビットと同様で、奇数値のフィールドはオプションであることを示すため（↑ではasset_key_familyとasset_typeがオプション）。1と5使ってないのは何でだろう？
アセットの受信者は、受け取りたいアセットの情報と、受け取りに使用する鍵（asset_script_keyとinternal_key）から↑のTaroアドレスを生成する。
tarocliでアドレスを生成
tarocliのaddrs newコマンドを使用すればTaroアドレスが生成される。前回1,000発行したアセットを500ほど受け取るアドレスの生成は↓
$ tarocli addrs new --amt 500 --genesis_bootstrap_info a92eb9e8d42437b8879ff571903fcbb74b55fc558c3cbc80ba8ca293bcd82eaf000000010874657374636f696e116d6574616461746120666f7220746573740000000000 { "encoded": "tarotb1qqqsqqjy4yhtn6x5ysmm3pul74ceq07tka94tlz43s7teq963j3f80xc96hsqqqqqyy8getnw33k76twz9kk2arpv3shgcfqvehhygr5v4ehgqqqqqqqqppq5746x7psp9fvl0mhs6f80zcnpzlch5v97xh46j6459sy80supf9svgzkf72uhhmf2a2ma8s8glra7dqagk96n47fda64q6dkmu32xjfw7syq8lgp7syf8tft", "asset_id": "9333d8360be674dfae320b7ae16bd3b618726637fad107a1d2b248a3083061ca", "asset_type": "NORMAL", "amount": "500", "family_key": null, "script_key": "02a7aba378300952cfbf778692778b1308bf8bd185f1af5d4b55a16043be1c0a4b", "internal_key": "02564f95cbdf695755be9e0747c7df341d458ba9d7c96f755069b6df22a3492ef4", "taproot_output_key": "37fc965befde457f4c7943750d83a5743a565fb12eaf7c01c3084fe8b106f533" }
アセットの情報はgenesis_bootstrap_infoで指定する。このデータは、アセット発行の際に使用したアセットジェネシスのデータ（アセットIDを算出する際のデータ）になる。tarocliではassets listコマンドの出力結果にも含まれている。
受信者は↑のbech32mアドレスを送信者に送り、送信者はそのアドレスから送金先のTaroアウトプットを作成することになる。
taproot_output_keyは、500個分のアセット9333d8360be674dfae320b7ae16bd3b618726637fad107a1d2b248a3083061caをリーフノードとして空のMS-SMTツリーに挿入してTaroのアセットツリーを構成し、それとinternal_keyをTaprootの内部鍵として利用して計算したTaprootのwitness programになる。そのため、実際に受信者が受け取るTx内のアウトプットのscriptPubkeyは、
OP_1 <37fc965befde457f4c7943750d83a5743a565fb12eaf7c01c3084fe8b106f533>
となり、P2TRアドレスに変換すると、
tb1pxl7fvkl0mezh7nregd6smqa9wsa9vha396hhcqwrpp873vgx75es923e09
となる。
tarocliで↑のアドレスを作成した段階で、連携先のlndのウォレットにこのアドレスがインポートされていることが確認できた。
単純に、↑のP2TRアドレスをTaroアドレスとしないのは、どういったツリーが構成されるか送信者も検証する必要があるからかな。
