monaka/README.md

## README.md

      
    Raw
  

              README.md
            
          
    Single-use seals については、発案者である Peter Todd 氏による平易な実例付きブログ記事が存在する。
しかし、verification の手前でどのような操作を行ったのか、丁寧に読めば判るのだが、ハッシュだらけで混乱しやすい。
本文書では、補完する情報として、行ったであろう操作手順を再現記録する。
3.2.0 seal

2016 年 12 月 1 日

支払証明の作成

まず、支払証明 (solvency proof) ファイルを作成する。
acme-solvency-proof-dec-1st-2016.txt は下記の通り。
Acme Bitcoin Exchange Solvency Proof
====================================
Dec 1st 2016

Alice   - 10 BTC
Fred    - 17 BTC
Mallory -  5 BTC
Pia     - 14 BTC
Wendy   - 33 BTC

<proof Acme controls 79 BTC as of Dec 1st 2016>

支払証明の SHA256 チェックサム値を得る。
534a405f376cd55c7cd41676dd728a729d0c536385e2e6e0beb7257bac752c01  acme-solvency-proof-dec-1st-2016-header.txt

支払証明のヘッダファイルを作る

ヘッダファイル acme-solvency-proof-dec-1st-2016-header.txt には、支払証明のチェックサム値と、次回 seal として利用予定の UTXO を含める。
 Solvency: 534a405f376cd55c7cd41676dd728a729d0c536385e2e6e0beb7257bac752c01
Next Seal: 5b6705437ced5cca8ec52cfb187e5d3270e067817c4fcd5a26755d4ceb4c010c:0

ヘッダファイルの SHA256 チェックサム値を得る。
d28a129cd4475132846a49f84a85fc8cad4330622a6a8103a3e8c446f3d9ae4c  acme-solvency-proof-dec-1st-2016-header.txt

OP_RETURN にヘッダファイルの SHA256 チェックサム値を加えた output を含むトランザクションを作成し、送信する。
Bitcoin mainnet に取り込まれた例は、ブロックチェーンエクスプローラで確認できる。
txoutproof の取得(オプション)

explorer を使ってもトランザクションの確認はできるが、bitcoin-cli の gettxoutproof を使ったほうがトラストレス。
取得された hex を、ファイル tx-proof-976e842f944b797352a111893d766ce1b3b211d987d31e764a424ee19de10fe5.txt に保存する。
情報の公開

上記で作成した *.txt　を全て検証者にオフチェーン公開する。
2016 年 12 月 2 日

支払証明の作成

昨日と同様に、支払証明 (solvency proof) ファイルを作成する。
acme-solvency-proof-dec-2nd-2016.txt は下記の通り。
Acme Bitcoin Exchange Solvency Proof
====================================
Dec 2nd 2016

Alice   -  5 BTC
Fred    - 15 BTC
Mallory -  3 BTC
Pia     - 10 BTC
Wendy   - 35 BTC

<proof Acme controls 65 BTC as of Dec 2nd 2016>

支払証明の SHA256 チェックサム値を得る。
8c055d6890ab8b315618c3ba0c89ec83bc0291ae43c93ee0edc238b7865f09f3  acme-solvency-proof-dec-2nd-2016-header.txt

支払証明のヘッダファイルを作る

ヘッダファイル acme-solvency-proof-dec-2nd-2016-header.txt の構造は、昨日作ったヘッダファイルと同様。値は異なる。
 Solvency: 8c055d6890ab8b315618c3ba0c89ec83bc0291ae43c93ee0edc238b7865f09f3
Next Seal: c68fe1abc91e294c600911fc17db71ee627c9f3ad0fcf428c34fd1e804ed9859:0

ヘッダファイルの SHA256 チェックサム値を得る。
1bfeebbef0a0daa230992d037f0b6cc7eeb12b6d02c7261be63838dc8dfc7a80  acme-solvency-proof-dec-2nd-2016-header.txt

input として昨日のヘッダファイルに記録した Next Seal (つまり 5b6705437ced5cca8ec52cfb187e5d3270e067817c4fcd5a26755d4ceb4c010c:0 )、 OP_RETURN にヘッダファイルの SHA256 チェックサム値を加えた output を含むトランザクションを作成し、送信する。
Bitcoin mainnet に取り込まれた例は、ブロックチェーンエクスプローラで確認できる。
txoutproof の取得(オプション)

explorer を使ってもトランザクションの確認はできるが、bitcoin-cli の gettxoutproof を使ったほうがトラストレス。
取得された hex を、ファイル tx-proof-19c2aa81cf6a0bf7d1f20810ca72baac44cb2532d765e162b0d58b4e050ff3af.txt に保存する。
情報の公開

上記で作成した *.txt　を全て検証者にオフチェーン公開する。
1016年12月3日以降

Bitcoin mainnet チェーンと公開された *.txt ファイル、および sha256sum 相当のツールがあれば、支払証明の改ざんを検知できる。
具体的な方法は、先に紹介した Peter Todd 氏のブログにある。
余談

reorg + double spend が成功した場合を除き、utxo は input として使われると utxo に戻れない。
そしてこのトランザクションは header が繋ぐチェーンとなる。チェーンが先に進むほど、過去の改ざんの難度は上がる。これはブロックチェーンで過去の改ざんが困難な理由と相似である。
Next Seal が1つしか存在しない場合、分岐は不可能となる。
Ethereum でいう global state に相当する情報を、一つのチェーン内で非中央集権的に管理できる。
これが RGB protocol が Single-use seals を採用した理由と思われる。
筆者は、本文書を書いている時点で RGB protocol の全貌を掴めていないので、想像だが。
おそらく、下記の需要を満たすために RGB のスマコンは存在し、AluVM が実装されている。

genesis transaction が異なる2つのアセットの交換
genesis transaction が同じアセットの総量増減