5章_トランザクション
whitecat6142.iconしろねこ
ノート
5.1
従来のシステムの問題点
リサの信頼の問題
リサが故意に送られてきたメールと違う内容を書き込んだらどうなってしまうか
それぞれの公開鍵ハッシュ(≒アドレス)に入っている残高を逐一チェックしないといけない
ユーザー数と取引数が増えていくと爆発的に大変になる
２つ以上のアドレスからの支払いに対応していない
プライバシーのために同じ人が２つ以上のアドレスを持っているような仕組みに なっているのに一度に１つのアドレスしか使えない
10CT持っていても一度に支払えるのは5CTのみという状態になってしまう
誰にでも検証できるようにフォーマット化する
->トランザクション
ポイントは必要とされる信頼を最小化すること
5.2
どこからきたお金なのか明確化する=支払い能力があることを証明する
->UTXO(未使用トランザクションアウトプット)
必要なもの
txid
トランザクションのハッシュ
ハッシュはダブルSHA-256
そのトランザクションでの出力インデックス
どの公開鍵ハッシュか指定する
署名
それぞれの公開鍵ハッシュに対応する秘密鍵で行う
署名部分以外の全てに対して署名する
全ての入力に対して行う
全ての署名蘭が空の状態に署名するので署名の順序は問われない
公開鍵そのもの
公開鍵ハッシュでは検証ができない
トランザクション手数料=入力-出力
入力と出力がぴったり一致している必要はない
残りはマイナーに支払う手数料になる
UTXOセット
各ノードがもっている
二重支払い攻撃(すでに使われたお金で支払いをすること)に対処するための検証に用いる
新たな承認済みトランザクションが送られてくる毎に更新し続ける必要がある
この情報は全ブロックを走査することで再構築することが可能である
フルノード
合意されたルールにしたがって更新されているかチェックする検証者
公開鍵が公開される
同じアドレスを再利用しないことが求められる
値ベース
口座にいくら残高があるかではなくコインを管理しているのに近い
UTXOは任意の値を示す分割可能なコインのようになっている
例えて言うなら今まで逐一銀行のATMに行って残高を確認してから送金していたのがハンコの押された約束手形の束を持って歩くように変わった感じ
5.3
Scriptという小さなプログラミング言語で実際は構成されている
一つのトランザクション入力に対して以下の操作を行う
公開鍵スクリプト
署名スクリプト
公開鍵スクリプトは送金者側が書き込み
署名スクリプトは受け取った人が使うときに書き込む
署名スクリプト、公開鍵スクリプトの順で実行しトランザクション内の全ての命令を実行した最終結果がOKであればトランザクションは真正だと定義する
スタック(最後に入れたデーターが最初に取り出される)で途中データーを管理する
署名をあらかじめ決められたプログラムに入力として入れるイメージ
P2PKHの場合
署名スクリプト
署名データー、公開鍵を順番に入れる
スタックの状態
上
公開鍵
署名データー
公開鍵スクリプト
OP_DUP
公開鍵をコピーしてスタックへ
OP_HASH160
一番上の公開鍵を公開鍵ハッシュへ
比較したい公開鍵ハッシュ
OP_EQUALVERIFY
上2つのデーターを比較して異なっていたらエラーをおこし合っていたら次へ進む
OP_CHECKSIG
公開鍵と署名を取り出して検証する
結果はスタックに置く
以上で終了
結果がOK(=true)ならトランザクションは真正とみなす
プログラムになっている理由は柔軟性のため
さらにそれを発展させたものとしてイーサリアム上で動くSolidityによるスマートコントラクトとかもある
スクリプトは書き換えても署名に影響がないためここを書き換えることでtxidを変更することができるという脆弱性
現在のsegwitでは起こり得ない(らしい)
ちなみにビットコインができる前のもともとの設計はもっとSimpleな実装の予定だったらしいが…
5.4
スクリプトになっていることになっていることを活かした幾つかの送金方法について説明する
P2PKH(pay-to-pubkey-hash) :これまで
1からはじまるアドレス
pay-to-hash
ハッシュの現像を持っている人に支払い
従来の問題点
共同基金をつくることを考える
管理してる人が死んだり鍵をなくすと基金を回復できなくなる
管理してる人が鍵を盗まれるリスク
管理してる人が高跳びする可能性
権限を分散できたら
->マルチシグ
マルチシグ
3つの鍵のうち2つの鍵で署名したら有効といったことができる
どれかひとつが失われてもきちんと有効につかえる
鍵1つだけではつかえない
具体的にはOP_CHECKMULTISIGを使う
例ではスタックに
"0" 署名2つ "2" 公開鍵3つ "3"
を置いてから
OP_CHECKMULTISIG
で2つの署名と3つの公開鍵を受け取ってtrue/falseを返している
問題点
送金する人がOP_CHECKMULTISIGを知っている必要がある(あまり拡張性がない)
+送金側の手数料が高くなる
->scriptのhashを送り先にする
P2SH(pay-to-script-hash)
つかう予定の公開鍵スクリプトのハッシュだけを公開する
具体的には
支払い時に署名とredeem scriptという"データー"をスタックにプッシュする
P2SHに対応していないソフトウェアはそのままredeem scriptをそのままハッシュして OP_EQUALで比較して検証する(なぜこれで上手くいくかというとpay-to-hashになっているから)
P2SHに対応した新しいソフトウェアはスクリプトのパターンからP2SHを検出して途中でredeem scriptをプログラム領域に移して実行する
マルチシグではredeem scriptには3つの公開鍵とOP_CHECKMULTISIGが入っている
このredeem scriptを含めたスクリプト全体の実行が通ればOK
3からはじまるアドレス
OP_RETURN(P.342 おまけ)
使えないアドレスにする
データーを刻み込んだりproof of burnに使ったりする
uxtoセットを浪費しない
5.5
トランザクションの残りは以下のようなものが入っている
バージョン
1,2がある
シークエンス番号
古い無効化された機能(デフォルトffffffff)
ロックタイム
追加されるまでの有効期限
(詳しくは9章)
5.6
報酬とコインの作成
コインベースという特殊な入力からコインが発生する
このトランザクションをコインベーストランザクションという
全てのコインはどこからやってくるので元を辿ればコインベースに辿り着く
(ここではリサが勝手に作っているが普通はマイニングによって得られる)
5.6
この本ではリサが管理していたシステムから移行したという形になっている
この場合最初のブロックにいままで取引していた全ての口座の残高を提示する巨大なトランザクションを生成する
(これは以前のシステムを知らない人たちには検証できない)
ビットコインでは違う
空のUTXOセットからスタートだった
プレマイニングみたいな状態
作者等があらかじめ初期のブロックで大量のコインを保有していたりする
通常の取引が始まった時点で残高を持った人たちが沢山いるので
5.7
もうあまりリサに依存していない
現状依存しているのは以下の2点
検閲しないこと
送受金者で選り好みしていないかどうか
取り消さないこと
一度支払ったトランザクションをなかったことにしないかどうか
払ったものを払っていないことにしたり複数の人に違ったシートをみせて会計をごまかしたりできる(二重帳簿みたいに)
ただ専用のDBにトランザクションを数珠繋ぎで挿入していくだけではなくどうして多くのマイナーが参加するマイニングというシステムによって承認される必要があるのかという話につながっていくんじゃないかと