Develop with pleasure!

福岡でCloudとかBlockchainとか。

ウォレットからラベルをエクスポート/インポートするフォーマットを定義したBIP-329

先日、Bitcoinのウォレットからラベルをエクスポートしたりインポートするためのフォーマットを定義したBIP-329が公開されたので見ておく↓

https://github.com/bitcoin/bips/blob/master/bip-0329.mediawiki

BIP-32のHDウォレットやBIP-39のようなニーモニックBIP−44によるマルチアカウント階層の定義など、マスターシードや拡張秘密鍵をエクスポートして他のウォレットにインポートすることで、ウォレット間の移行は割と簡単にできるけど、その際に各ウォレットで付けられたラベルの情報は欠落してしまう。

そんなラベルの情報もウォレット間で移行できるようにするため、エクスポート/インポートするためのフォーマットを定義しようというのがBIP-329。

データのフォーマットはJSON Linesフォーマットで、現在、以下のデータに対するラベルのフォーマットが定義されている。JSONベースなので、その後の拡張も簡単。

フォーマットの仕様や、実際のデータイメージは、↓のBIPの意訳参照。

概要

このドキュメントは、ウォレット内のさまざまな共通タイプのレコードに添付できるラベルのエクスポートフォーマットを定義する。

著作権

このBIPはBSD 2-clauseライセンス。

動機

異なるBitcoinウォレットアプリケーション間での、資金のエクスポートとインポート方法は、BIP39やBIP32、BIP44などの標準で明確に定義されている。これらの標準は十分にサポートされており、ユーザーは異なるウォレット間で資金を簡単に移動することができる。しかし、ユーザーが自分のウォレット内のトランザクションやアドレス、公開鍵、インプット、アウトプット、xpubに適用したラベルを移行するために定義された標準はない。Bitcoinが使用するUTXOモデルは、外部から受け取った資金であれ、前のトランザクションのお釣りとして受け取った資金であれ、資金の出所を示す可能性があるため、これらのラベルを価値あるものにしている。どちらの場合も、望ましくない個人情報の漏洩を避けるため、支払い時に注意を払う必要があり、ラベルはこの点で貴重なガイダンスを提供し、いくつかのBitcoinウォレットで使用する際に必須にもなっている。標準化された方法でラベルをインポートおよびエクスポートできるようにすることで、ユーザーが特定のウォレットアプリケーションにロックインされることが無いようにする。

論拠

現在、ラベルのエクスポートとインポート用に広く受け入れられているフォーマットはないが、いくつか使用されている既存のフォーマットがある。SLIP-0015は、アドレスとアウトプットのラベルをエクスポートするためのフォーマットを定義しているが、ウォレットシードと関連する秘密鍵を使用して暗号化する必要があるため、秘密鍵にアクセスできないコーディネーターウォレットが単独で使用することはできない。Electrumウォレットは、アドレスとトランザクションのラベルをJSON形式でインポート/エクスポートしており、他のレコードタイプでも使用できるものの、使用されているフォーマットは自己記述型ではないため、レコードタイプの識別が難しい。

仕様

このBIPでは、軽量で可読性が高く、構造化されているため、JSONフォーマットを使用する。さらにJSON Linesフォーマットを使用する。これにより、ドキュメントの分割や、ストリーミング、インクリメンタルな追加が可能となり、フォーマットエラーによるインポート全体の無効化の可能性を制限することができる。また、行指向であることが多いコマンドライン処理にも便利な形式である。

JSON Lines仕様に加えて、ウォレットからのラベルのエクスポートは、有効なJSONオブジェクトで構成される1行につき1レコードを含むUTF-8エンコードされたテキストファイルである必要がある。行は\nで区切られる。複数行の値は許可されない。各JSONオブジェクトには、以下に定義する3つのkey/valueのペアが含まれていなければならない:

キー 定義
type txaddrpubkeyinputoutputxpubのいずれか。
ref トランザクション、アドレス、公開鍵、インプット、アウトプットまたは拡張公開鍵への参照。
label 参照先に適用されるラベル

参照は、以下のようにタイプごとに定義される:

タイプ 定義 サンプル
tx hexフォーマットのトランザクションID f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd
addr base58またはbech32フォーマットのアドレス bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c
pubkey 32、33、65バイト公開鍵のhexフォーマット 0283409659355b6d1cc3c32decd5d561abaac86c37a353b52895a5e6c196d6f448
input コロン区切りのトランザクションIDとインプットのインデックス f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:0
output コロン区切りのトランザクションIDとアウトプットのインデックス f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:1
xpub BIP32で定義されている拡張公開鍵 xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8Nq...

プライバシーに配慮したデータであるため、エクスポートする際には注意が必要。信頼できないネットワークを経由する場合は、暗号化を強く推奨し、保管中の暗号化も検討する必要がある。暗号化されていないエクスポートデータは、できるだけ早く削除する必要がある。セキュリティ上の理由から秘密鍵のタイプは定義されていない。

インポート

  • インポートするウォレットは、保存していないレコードを無視し、必要に応じてラベルを切り捨てることができる。
  • 公開鍵レコードをインポートするウォレットは、既知のウォレットアドレスと照合するため、、それらからアドレスを導出する場合がある。
  • 拡張公開鍵をインポートするウォレットは、例えばマルチシグの設定において、署名者と照合する場合がある。

後方互換

このフォーマットの性質により、他のレコードタイプを処理できるように自然に拡張することができる。ただし、この仕様に準拠したウォレットをインポートする場合、ここで定義されていないタイプは無視される可能性がある。

Test Vector

以下の断片が、ウォレットラベルエクスポートを表している。

{ "type": "tx", "ref": "f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd", "label": "Transaction" }
{ "type": "addr", "ref": "bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c", "label": "Address" }
{ "type": "pubkey", "ref": "0283409659355b6d1cc3c32decd5d561abaac86c37a353b52895a5e6c196d6f448", "label": "Public Key" }
{ "type": "input", "ref": "f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:0", "label": "Input" }
{ "type": "output", "ref": "f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:1", "label": "Output" }
{ "type": "xpub", "ref": "xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8", "label": "Extended Public Key" }