ブロックチェーン仕組みと理論 読書メモ
https://scrapbox.io/files/6760c9e75e6f16ee1d2a2c44.png
やっと時間がある時に勉強したかった本が読める📕
1章
注ぎ込んだ原価は価値にそのまま変換されるわけではない
/emoji/tea.icon 本当その通り
冷静に技術について考えていきましょう
/icons/hr.icon
2章 ブロックチェーンに至るまで
ブロックチェーンとビットコインは同時に生まれたと言っても過言ではない
取引所の破綻やコインの技術による分断などを経て今に至る
/emoji/tea.icon 色々あったなぁ
各部隊はそれぞれ離れた場所にいて、伝令を相互に送ることでしか連絡できない。戦局は、将軍たちがいっせいに指令を出して攻撃を仕掛ければ勝てるが、一部の部隊だけで攻撃を仕掛けると負けてしまうという状態。つまり、攻撃か撤退かのどちらかを、全将軍が一致して同意しなければならないのだ。しかし、将軍たちの中には裏切り者、つまり敵に寝返っている将軍がいるかもしれない。裏切り者の将軍は、他の将軍から攻撃の提案を受けると、撤退の提案にすり替えて別の将軍に伝達するかもしれない。そうなると、一部の将軍は攻撃指令と撤退指令の両方を受け取ることも想定される。最悪、一部の部隊だけが攻撃を開始してしまい、負ける可能性もある。
価値のインターネット（情報の信憑性）を担保できる技術がブロックチェーン
/icons/hr.icon
3章 ブロックチェーン技術とは？
そもそもの課題は取引における第三者の負担だった
それに伴う手数料が取れない場合の少額取引も然り
信頼できる第三者の仲介なしに取引できる方法を考える必要があった
分散型台帳
エクセルの共有ブックのようなもの
同じデータへの書き込みは使用者巻のルールに則って合意のもと進められるイメージ
平等性
仲介者がいないとも言える
透明性
改ざん体制
ツアー旅行が個人の民泊利用になったのもこれに似ている
/icons/hr.icon
4,5章 ブロックチェーン技術の応用、動向
農業
医療
不正な改竄を防ぐ
チケット管理
転売防止
/icons/hr.icon
6章 理論編
ビットコインの仕組み
分散型システム。PCのリソースを全員で相互に使っている感じ。中央集権的なサーバーはない。
前の所有者から別の所有者への名義変更をやっている
本人証明
内容の非改ざん性
これらを証明するために、電子署名という仕組みを利用する
ただ、それだけでは電子通貨が使用済みかどうかがわからない
そこで、すべての取引（トランザクション）を台帳（ブロックチェーン）に記載する
ただそれでも、全員でデータを共有しているので改ざんの可能性は上がる
そこで、取引をさらに「ブロック」という単位でまとめて
各ブロックに前のブロックの情報（ハッシュ値）を持たせて接続する
ナンスというものもブロックの中に組み込まれる
トランザクション
ブロックチェーン
ブロック
ナンス
ハッシュ計算で求められるパラメーター
ハッシュ値
前の取引の要約だと思えばいい
後から改ざんして不正な取引にしようとしても、ブロックの数*ナンスを求める10分がかかる
なぜならブロックが前のブロックのハッシュ値を持っているから
P93を参照
GPT要約
例えば「ターゲット」が
0000000000000000000abcdef123456789abcdef000000000000000000000000
のような小さめ（先頭にたくさんの0が並ぶ）の16進数だとします。マイナーはブロックデータ＋ナンス（例えば 12345 など）をSHA-256にかけ、以下のような256ビットのハッシュ値を得ます。
rust
コードをコピーする
(ブロックヘッダ + nonce=12345) -> SHA-256 -> ハッシュ値 = 00000000000ffef...
このハッシュ値がターゲットより小さければマイニング成功、つまり「クリア」です。もし大きかった場合はナンスを 12346, 12347, … と変えながら再計算を繰り返し、成功を狙います。
結論：ナンスを試行してハッシュを計算し、その結果が「ターゲットより小さい値」になったらマイニング成功。これがビットコインマイニングの肝です。
ブロックヘッダにはタイムスタンプとかも含まれている
/emoji/tea.icon 自分の言葉で
ビットコインの取引（トランザクション）では、履歴をブロックチェーン（台帳）と呼ばれるものに記録している。取引とは、どのくらいの量のビットコインが誰から誰に渡るかを記録する作業で、その正当性をユーザー全体で承認しており、銀行のような信頼できる第三者やサーバーは仲介しない。トランザクションの内容として、1つの取引はブロックという単位でブロックチェーンに刻まれる。（刻まれた結果がブロックチェーンでもある）ブロックには、前の取引を要約したハッシュ値が記録されている。取引承認時に、ターゲットという値が決まっており、いち早くその値より小さな値になるハッシュを見つけるためのナンスを見つけた人に報酬が与えられる（マイニング）
→あっているか確認と訂正
修正後の文章
ビットコインの取引（トランザクション）は、複数まとめてブロックという単位で管理され、これらのブロックを連続的につなげたものがブロックチェーン（台帳）である。
取引（誰から誰にどのくらいのビットコインが送られたか）の正当性は、銀行のような中央管理者ではなく、ネットワーク全体で承認される。つまり、特定のサーバーを仲介しなくても、改ざんされにくい形で履歴が保たれている。
ブロックには、前のブロックのハッシュ値（要約情報）や、新規のトランザクション情報などが含まれており、それをまとめて「ブロックヘッダ」と呼ぶ。ビットコインのマイナーは、このブロックヘッダに含まれるナンス（nonce）という数値を何度も変えながらハッシュ値を計算し、ターゲット（あらかじめネットワークが決める基準値）より小さいハッシュ値が出るかどうかを探す。
この計算に成功し、有効なハッシュが見つかった瞬間、そのブロックは正式に「承認」され、取引はブロックチェーンに刻まれる。
さらに成功したマイナーには、ビットコインの新規発行分や手数料が報酬として与えられる。これがマイニングの仕組みである。
ブロックは「1取引=1ブロック」ではない
1回の送金（トランザクション）だけでブロックが作られるわけではありません。
ビットコインではマイナー（採掘者）がネットワーク上にやってきた複数の取引をまとめてブロックを作り、そのブロックをマイニング（ハッシュ計算）して承認されるとチェーンに追加される仕組みです。
したがって、A→Bの1BTC送金も、同時期に発生した他の送金・取引データと一緒に1つのブロックに収められます。
なんとなく理解できたが、動画とかで確認したい気もする。
P95〜わかりやすい
なるほど、まずそもそも自分の鍵で電子署名するから、マイナーの手元に来る頃には正しい取引だってことが保証されているのか
ほぼ合っています！ただ、もう少し正確に言うと：
マイナーの手元に届く時点で「正しい可能性が高い取引」だと分かっている、という状態です。完全に「保証されている」わけではなく、最終的にはマイナーやネットワークのノードが取引の検証を行い、正当性を確認することでブロックに取り込まれます。
詳しい流れ
取引の作成と署名
Aさんが自分の秘密鍵でトランザクション（例えば「50BTCをBさんに送る」）に署名をします。これにより、「この取引はAさん本人が作ったものだ」ということが暗号学的に証明されます。
ネットワークへのブロードキャスト
署名済みの取引データはビットコインネットワーク上にブロードキャスト（通知）され、複数のノード（参加者）に届きます。
ノードによる検証
取引を受け取ったノードは、次のことを検証します：
Aさんの残高（UTXO）が送金額を満たしているか
署名が正しいか（秘密鍵を使って署名したか）
同じUTXOが別の取引で使われていないか（ダブルスペンド防止）
→ 検証に問題がなければ「有効な取引」として扱われます。
マイナーが取引をブロックに含める
マイナーは、ネットワークから集めた「有効な取引」をまとめてブロックを作成し、マイニングを行います（ハッシュ計算をしてターゲット未満のハッシュを探す）。
ブロックの承認とチェーンへの追加
マイニングに成功したマイナーが作ったブロックはネットワークに伝播し、他のノードがそのブロックを検証します（含まれる取引の正当性やハッシュの整合性など）。
問題がなければブロックチェーンに追加され、取引が正式に承認されます。
重要なポイント
署名済みの取引がネットワークに届く時点では、署名が正しいかは確認されていない。
ノードやマイナーが「署名」「残高」「二重使用」などを検証し、正しい取引だけがブロックチェーンに取り込まれる。
したがって「署名があるから正しい取引だ」とは言い切れず、最終的にはネットワーク全体の検証によって「正しい取引だ」と確認されるのです。
マイニング
1. 生成の仕組み
ビットコインが新しく生成されるのは、マイナーが新しいブロックをマイニング（発見）したときです。
コインベーストランザクション：
マイナーは新しいブロックを作るときに、必ず**「コインベーストランザクション」**という特殊な取引を最初に含めます。
これは「マイニング報酬（新規ビットコイン）」を自分のアドレスに送る取引です。
この取引には「送り元」が存在せず、完全に新しいビットコインがブロックチェーン上で生成されます。
なるほど。あとはトランザクションの手数料ももらえるから、マイニング報酬がなくなってもそれ欲しい人は続けるか。
じゃあ最終的に手数料高くならないか？って思ったら、そこで取引をまとめたりライトニングネットワークみたいな話になるのか
/emoji/tea.icon P2P、電子署名、コンセンサスアルゴリズム、ハッシュ、これを組み合わせてビットコインができている
/icons/hr.icon
7章 P2Pネットワーク
各コンピューターはノードと呼ばれる
サーバーが単一障害点にならない
ピュアとハイブリッドがある
オーバーレイネットワークとは
既存のインターネット回線の上に論理的・仮想的に作られるネットワーク層
ノード同士は物理的接続関係に左右されず、プロトコルで定められた論理的なつながりを持つ
構造オーバーレイと非構造オーバーレイで分けられる
メッセージ伝播の仕組み(ブロードキャスト、共通)
ビットコインのトランザクションやブロック情報は、受信したノードが次々と他の接続ノードへ転送していく
この連鎖的な伝播によってネットワーク全体へ情報が行きわたる
構造オーバーレイと非構造オーバーレイの比較
構造オーバーレイ
特徴: ノード間接続が論理的なルールやアルゴリズムで組織化されている(DHTなど)
データ探索: ノードIDやキーに基づく効率的なルーティングが可能
ネットワーク維持コスト: ネットワーク上のノード配置やルーティング構造のメンテナンスが必要
メリット: 検索効率が高く、特定の情報を素早く特定可能
デメリット: システム設計が複雑で、ノードの参加・離脱への対応が大規模になると管理が煩雑
非構造オーバーレイ（ビットコインはこっち）
特徴: 明確な規則なく自然発生的にノードが接続する(ビットコインなど)
データ探索: ブロードキャスト(洪水的手法)によるトランザクションやブロックの拡散
ネットワーク維持コスト: 構造の維持は不要で、単純な接続のみで成立
メリット: 設計がシンプルで、分散性・耐障害性が高い
デメリット: 特定の情報探索には効率が悪く、無駄な通信が多発する可能性がある
/emoji/tea.icon マイニングの仕組みに使われていることが明らかにわかる。
データー送信時にも、いきなりデータを送らずハッシュを渡して持ってなかったら渡す遺体な仕組みがある
P122
エクリプス攻撃は、悪意のある人間がネットワーク上のノードを妨害する比較的単純な攻撃です。
課題もある
/icons/hr.icon
8章 コンセンサスアルゴリズム
そもそもの課題：伝達情報のタイムラグや未到達の事態
確かに、P2P使ってるならこれは起こりうる。いわゆるビザンチン将軍問題など。
PoSがビザンチン将軍問題を解決しうる理由
PoS（Proof of Stake）では、ネットワーク参加者（バリデータ）が自らの「資産（ステーク）」を担保にブロック生成や検証を行うため、不正行為を行うとその資産が没収されるリスクがある。この経済的インセンティブ構造により、参加者は正直に振る舞うことが合理的な選択となり、結果的にビザンチン将軍問題（不正な情報伝達を行うノードがいても全体として正しい合意が得られる問題）を解決可能になる。
不正な行為をすると没収できる：スラッシュ
PoWの問題点（気になる）
1. 51%攻撃 P128
長いチェーンをずっと持っておいてブロードキャストせずに、タイミングを見て長くなったら放つ
2. ファイナリティの不確実性
どれが最終取引かわからないので、意図した変更が行われる可能性がある
ケース例
たとえば、レストランのオーナーが仮想通貨で支払いを受けるとします。ファイナリティ（取引が取り消し不可能な状態）が確保されていない場合、支払いが完了したと思って料理を提供した後、実は取引が「巻き戻り」（ブロックチェーンの分岐などで無効化）してしまい、オーナーが代金を受け取れないケースが起こり得ます。これが、ファイナリティ不足による問題の一例です。
3. 性能限界
レスポンスタイム
4. ブロックチェーンの容量
初回起動やばそう、単純に
/emoji/tea.icon Byzantine Fault Tolerance の略なんだ...w
PoW
/emoji/tea.icon P133に詳しい図があるが、要は参加者が仕事をした結果チェーンが伸びて、長いものが正しいとされる。
PoS
/emoji/tea.icon PoSは多い所有者が有利な設計差が、51%攻撃がやりづらくなる。マイナーが通貨を抱え込むリスクなどはある。流動性は下がるだろうし、所有者有利は中央集権と変わらないのでは？と思った。
PoA
Proof of Authority (PoA) は、信頼された特定のバリデーターがブロック生成を行うコンセンサスアルゴリズムです。高速かつエネルギー効率が高いのが特徴で、主に企業やプライベートブロックチェーンで利用されます。一方で、バリデーターが事前に選ばれるため中央集権的であり、分散性には欠けます。許可型ネットワークや効率性を重視する用途に適しています。代表例として、Ethereumのサイドチェーンや物流システムでの活用があります。
PBFT
リーダーを決めて、投票の後チェーンを増やす。リーダーの動きも監視されている。PoS PoWの問題点に対応。
全員と意思疎通する大変さはある。数十ノードが限界と言われている。
他にも色々...状況に応じて使うコンセンサスアルゴリズムも変わってくる。
/icons/hr.icon
9章 電子署名とハッシュ
電子署名は理解が簡単。自分の情報を非公開鍵で暗号化して一緒に送る。改ざんのないことを証明。
ハッシュ値あたりの話はプログラミングの知識でいけそう。
ナンスとの関係がうまく説明できない。
マイナー（ブロックを生成する人）は、ブロック内のデータ（取引情報など）にナンスを加えます。
このデータ全体をSHA-256でハッシュ化します。
ハッシュ値の先頭がターゲット（例: 先頭に4つの0）を満たしているかチェックします。
条件を満たしていなければ、ナンスを少し変更して再計算します。
条件を満たすナンスを見つけるまで、このプロセスを繰り返します。
こうか。
秘匿化などについても議論されているが、マネロンなどの危険性もある
/icons/hr.icon
10章 利用にあたっての課題
速度を担保しようとするとPoS寄りになっていくが、とはいえそれは根本の参加者の平等な合意による対改ざん性の根本を揺るがすことにもなる
/icons/hr.icon
実践編
Bitcoin Core
テストネット使うのが良さそう。
Dockerで動かせるみたい。macでも動くといいが、最悪EC2とかでやろう。
案の定詰まったので指定してビルドしてみる。
docker build --platform linux/amd64 .
platform: linux/x86_64
いけたっぽい。
code:plain
Attaching to btcd-1, btcd-2, btcd-3
btcd-2 | Bitcoin server starting
btcd-3 | Bitcoin server starting
btcd-1 | Bitcoin server starting
regtestモードで動かしてみる
code:plain
docker exec 500afef75180 bitcoin-cli getblockchaininfo
{
"chain": "regtest",
"blocks": 0,
"headers": 0,
"bestblockhash": "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206",
"difficulty": 4.656542373906925e-10,
"mediantime": 1296688602,
"verificationprogress": 1,
"initialblockdownload": true,
"chainwork": "0000000000000000000000000000000000000000000000000000000000000002",
"size_on_disk": 293,
"pruned": false,
"softforks": [
{
"id": "bip34",
"version": 2,
"reject": {
"status": false
}
},
{
"id": "bip66",
"version": 3,
"reject": {
"status": false
}
},
{
"id": "bip65",
"version": 4,
"reject": {
"status": false
}
}
],
"bip9_softforks": {
"csv": {
"status": "defined",
"startTime": 0,
"timeout": 9223372036854775807,
"since": 0
},
"segwit": {
"status": "active",
"startTime": -1,
"timeout": 9223372036854775807,
"since": 0
}
},
"warnings": ""
}
1. chain
値: "regtest"
意味: 現在接続しているブロックチェーンの種類。
regtest: 開発者用のテストチェーン。ローカルで動作し、任意のタイミングでブロックを生成可能。
他に main (本番ネットワーク) や test (公開テストネットワーク) もあります。
2. blocks / headers
値: blocks: 0, headers: 0
意味:
blocks: ブロックチェーン上の現在のブロック数。
headers: ブロックチェーンのヘッダー数 (未ダウンロードの部分も含む)。
状態: まだブロックが一つも生成されていない状態です。
3. bestblockhash
値: "0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206"
意味: 現在の最新 (best) ブロックのハッシュ値。
ハッシュはブロックのデータを表す一意の文字列。
4. difficulty
値: 4.656542373906925e-10
意味: 採掘 (マイニング) の難易度。
非常に小さい値なのは、regtest がテスト用で難易度を低く設定しているため。
mainnet (本番) だと非常に大きい値になります。
5. mediantime
値: 1296688602
意味: 最新ブロックの中央値のタイムスタンプ (Unix タイム形式)。
現在のタイムスタンプから見て古い値なので、regtest 環境のデフォルト状態の可能性が高いです。
6. verificationprogress
値: 1
意味: ブロックチェーンの同期進行度。
1 は完全同期を示す。
7. initialblockdownload
値: true
意味: ノードがまだ「初期ブロックダウンロード (IBD)」中であることを示すフラグ。
regtest では最初のブロックが未生成であるため true。
8. chainwork
値: "0000000000000000000000000000000000000000000000000000000000000002"
意味: このチェーンでこれまでに行われた作業量 (マイニング難易度 × ブロック数)。
regtest なので非常に小さい値。
9. size_on_disk
値: 293
意味: ディスク上のブロックデータのサイズ (バイト)。
データがほとんど存在しないことが分かります。
10. pruned
値: false
意味: プルーニング (不要な古いブロックを削除) の設定状態。
false はプルーニングが無効になっていることを示します。
11. softforks / bip9_softforks
意味: ソフトフォーク (ブロックチェーンの互換性を保ったアップグレード) の状態。
例:
"bip34": ブロックバージョン 2 以降の仕様 (status: false は無効)。
"segwit": Segregated Witness が有効 (status: "active")。
12. warnings
値: ""
意味: 現在のノードに関する警告メッセージ。
空なので、特に問題はありません。
要約
この情報は、現在のブロックチェーン (regtest) の状態に関するメタデータのセットです。何もブロックが生成されていない初期状態であることが分かります。
特に regtest は本番ネットワークではないため、外部に漏れても金銭的リスクやプライバシーリスクはほぼありません。
bitcoind
デーモンプロセス
ピア接続をやってみる
code:plain
docker exec -it 500afef75180 bitcoin-cli addnode 1f696b8711b0 add
docker exec -it 500afef75180 bitcoin-cli addnode 9ee2477e027e add
docker exec -it 1f696b8711b0 bitcoin-cli addnode 9ee2477e027e add
code:plain
docker exec 500afef75180 bitcoin-cli getpeerinfo
[
{
"id": 0,
"addr": "1f696b8711b0",
"addrbind": "172.18.0.2:60664",
"services": "000000000000040d",
"relaytxes": true,
"lastsend": 1734750781,
"lastrecv": 1734750781,
"bytessent": 453,
"bytesrecv": 336,
"conntime": 1734750781,
"timeoffset": 0,
"pingtime": 0.000593,
"minping": 0.000593,
"version": 70015,
"subver": "/Satoshi:0.18.0/",
"inbound": false,
"addnode": true,
"startingheight": 0,
"banscore": 0,
"synced_headers": -1,
"synced_blocks": -1,
"inflight": [
],
"whitelisted": false,
"minfeefilter": 0.00001000,
"bytessent_per_msg": {
"feefilter": 32,
"getaddr": 24,
"getheaders": 93,
"ping": 32,
"pong": 32,
"sendcmpct": 66,
"sendheaders": 24,
"verack": 24,
"version": 126
},
"bytesrecv_per_msg": {
"feefilter": 32,
"ping": 32,
"pong": 32,
"sendcmpct": 66,
"sendheaders": 24,
"verack": 24,
"version": 126
}
},
id:
ピアごとに割り振られる一意の識別番号。
この番号は、現在のセッション内でのみ有効。
addr:
接続先ピアのアドレス。ここでは 1f696b8711b0 という形式で表示されています。
通常、IPアドレスやホスト名が表示されるが、Docker内では名前解決の影響でこのような値になる場合もある。
addrbind:
ローカル側でピアがバインドされているアドレスとポート（172.18.0.2:60664）。
Docker内での内部ネットワーク上のアドレス。
services:
ピアが提供しているサービスのビットマスク。
000000000000040d は、ノードが何らかのサービス（例: ブロックデータ提供やトランザクションリレー）を提供していることを示す。
relaytxes:
このピアがトランザクションのリレーを許可しているか（true は許可）。
false の場合、このノードはトランザクションデータを受け取らない。
lastsend / lastrecv:
最後にデータを送信/受信したタイムスタンプ（Unix時間）。
ここでは 1734750781 として表示されていますが、日時を確認するには変換が必要です。
bytessent / bytesrecv:
このピアとの通信で送信/受信した総バイト数。
conntime:
このピアとの接続が確立されたタイムスタンプ（Unix時間）。
timeoffset:
このピアとの時刻同期のオフセット（秒）。
0 なら時刻が完全に同期している。
pingtime / minping:
pingtime: 最新のping応答時間（秒）。
minping: 過去の最小ping応答時間（秒）。
version:
このピアが使用しているビットコインプロトコルのバージョン番号（ここでは 70015）。
subver:
ピアが使用しているソフトウェアのサブバージョン。
/Satoshi:0.18.0/ は、このノードが「Satoshiクライアント」のバージョン0.18.0を使用していることを示す。
inbound:
接続が外部から発生したか（true なら外部からの接続）。
addnode:
addnode オプションで明示的に追加されたピアかどうか（true なら追加された）。
startingheight:
接続時にこのピアが持っていたブロックチェーンの高さ（ブロック数）。
banscore:
ピアに対する現在の「ペナルティスコア」。特定のルールに違反した場合、このスコアが増加し、一定値を超えると接続が遮断される。
synced_headers / synced_blocks:
このピアが最後に同期したヘッダーとブロックの数。
-1 は、まだ同期が始まっていないことを示す。
inflight:
このピアに要求したがまだ受信していないブロックリスト。
whitelisted:
このピアがホワイトリストに登録されているか。
minfeefilter:
このピアが受け入れるトランザクションの最低手数料（BTC単位）。
bytessent_per_msg / bytesrecv_per_msg:
各プロトコルメッセージごとの送信/受信バイト数。
例:
"version": 126 は version メッセージで126バイト送信。
"ping": 32 は ping メッセージで32バイト送信。
P186〜送金準備
送金したい
送金のためにはコインが必要
コインを得るためにはブロックの生成が必要
ブロックを作ろう、という流れ
多分マイニングがこれに当たるが、そこの手間をすっ飛ばしてるのではないだろうか
新しいアドレスを生成
docker exec 500afef75180 bitcoin-cli getnewaddress
2Mu6eeqSdL1KYs9m9G6JDDQUjGnxqQBtZ39
アドレスに対して101個のブロックを生成
docker exec 500afef75180 bitcoin-cli generatetoaddress 101 2Mu6eeqSdL1KYs9m9G6JDDQUjGnxqQBtZ39
1つ1つがブロックを示す。
情報を見る
docker exec 500afef75180 bitcoin-cli getblock 4a6cbdcf254310d0a3433e01c45dec97b45ca783b33258444c8208478a4111bf
code:json
{
"hash": "4a6cbdcf254310d0a3433e01c45dec97b45ca783b33258444c8208478a4111bf",
"confirmations": 1,
"strippedsize": 215,
"size": 251,
"weight": 896,
"height": 101,
"version": 536870912,
"versionHex": "20000000",
"merkleroot": "a103a425c5020d0b1f6422b263f0729d3db613292d7017e51db32f54dbd794c4",
"tx": [
"a103a425c5020d0b1f6422b263f0729d3db613292d7017e51db32f54dbd794c4"
],
"time": 1734751150,
"mediantime": 1734751149,
"nonce": 3,
"bits": "207fffff",
"difficulty": 4.656542373906925e-10,
"chainwork": "00000000000000000000000000000000000000000000000000000000000000cc",
"nTx": 1,
"previousblockhash": "4bb2e3a82abd4fbd7148bc1a9c5a5928855366a785e6b83449500a9dc319ca64"
}
ノード2、3のアドレスも作成
code:plain
docker exec 1f696b8711b0 bitcoin-cli getnewaddress
2MvCAqVyDcYeC81w2tvDhh5fDzN6LtHfLBE
docker exec 9ee2477e027e bitcoin-cli getnewaddress
2MtNravsFzdfDEuhwWrBehHehzkob4r9thv
残高確認
code:plain
docker exec 500afef75180 bitcoin-cli getwalletinfo
{
"walletname": "",
"walletversion": 169900,
"balance": 50.00000000,
"unconfirmed_balance": 0.00000000,
"immature_balance": 5000.00000000,
"txcount": 101,
"keypoololdest": 1734742429,
"keypoolsize": 999,
"keypoolsize_hd_internal": 1000,
"paytxfee": 0.00000000,
"hdseedid": "a34bee3b5c96a791d421faab98a43f48611f0ee8",
"private_keys_enabled": true
}
50BTC...
次送金から
コンテナ止めたらデータ消えてた
code:plain
2N8KxFxhmVuPpcEqUUMjizqjPkcnXqhKY7D
2Msto3j2pBi68Bjdw6tWiSxytU7WAzPanqh
2My8cfkoYT3fdzx5BDWz5q3CzKp32ahKRN4
docker exec 500afef75180 bitcoin-cli listunspent 0
code:plain
[
{
"txid": "1b9d6b3e7dc90fc723633b76022e27f340ee19f399543d76b75072e20240c246",
"vout": 1,
"address": "2N5xPshCKe6Q1XfNgov7BYxwWJiNPAKpTur",
"redeemScript": "00143570a3c30a5cf166bb1b35b16f1519a9eea0459c",
"scriptPubKey": "a9148b6ad10aca069d060b8c861bb88e2c556b34ba2187",
"amount": 39.99996680,
"confirmations": 0,
"spendable": true,
"solvable": true,
"desc": "sh(wpkh(320c979f/0'/1'/1'03511831d71ecf641e5a0ea984b09d09cda3eece8a4ac2d664fd69a8b8a6680dee))#pssa56l2", "safe": true
},
{
"txid": "1df210a5a7a57108d9032c591b8249156717991cb11f5754c8d2745b8b2c7f7c",
"vout": 0,
"address": "2N8KxFxhmVuPpcEqUUMjizqjPkcnXqhKY7D",
"label": "",
"redeemScript": "00146eeb8a528ec4e50bd0f70fc02686a5759d88e8dd",
"scriptPubKey": "a914a56ed608c43ba2203f059f2e7c65a611b470106387",
"amount": 10.00000000,
"confirmations": 0,
"spendable": true,
"solvable": true,
"desc": "sh(wpkh(320c979f/0'/0'/1'0339f70a3a8d9b10ad313c138a3dce901b9badd0cb02536864b7234e32e98b9e52))#03mskdd5", "safe": true
},
{
"txid": "1df210a5a7a57108d9032c591b8249156717991cb11f5754c8d2745b8b2c7f7c",
"vout": 1,
"address": "2NEgH9ozLHnoRDMueXiBB3rAp6ceNjGnLNz",
"redeemScript": "00146cd0dc398a86125ff50b8e327570e21e46623aa1",
"scriptPubKey": "a914eb17ae909fdc251c8636615268ab521e285e9f3f87",
"amount": 39.99996680,
"confirmations": 0,
"spendable": true,
"solvable": true,
"desc": "sh(wpkh(320c979f/0'/1'/0'03f2149c1d2d1b565cada23385915d9412d6c23def21069348d2ff38ca50e081f9))#3xwu2r6t", "safe": true
}
]
ノードとウォレットの違い
ノード
Bitcoinネットワークに参加するプログラム。
ブロックチェーンを保持し、ネットワーク内で取引の検証や伝播を行う。
自身のウォレットとは関係なく、全ネットワークの取引データを扱う。
ウォレット
ビットコインを送受信するためのキー（秘密鍵・公開鍵）を管理するツール。
ノード上で管理されることもあるが、外部（ソフトウェアやハードウェアウォレット）で独立して動作することも可能。
ウォレットが持つ「コイン」とは、実際にはウォレットが管理するアドレスに紐付けられたUTXO（未使用の取引出力）のこと。
docker exec 500afef75180 bitcoin-cli listunspent 0
0をつけることで未確定のトランザクションが出てくる
マイニングするとこれが確定する
本番だとどんな感じなのか
generatetoaddress は 本番環境（Mainnet） では利用できませんが、テスト環境（特にRegtestモード）で使われる便利なマイニング用コマンドです。本番環境でのマイニングと比較すると、かなり簡略化されています。以下にその動作と、本番環境で何が行われるかの違いを説明します。
テスト環境での generatetoaddress
このコマンドの動作を簡単にまとめると：
新しいブロックを生成する
Bitcoin Core はハッシュ計算のプロセスをスキップし、直接有効なブロックを作成します。
報酬の割り当て
ブロック生成の報酬（新規発行のBitcoin）を指定したアドレスに送ります。
チェーンを進める
指定した数のブロックを生成してチェーンを進めることで、トランザクションの承認をテストできます。
これにより、ハードウェアや多大な計算リソースなしでブロック生成が可能になり、テストや開発が簡単になります。
本番環境でのマイニング（何が起きるか）
本番のマイニングは以下のプロセスで進行します：
トランザクションの収集
ノードがメモリプール（mempool）から未承認のトランザクションを収集し、ブロック候補を作成します。
ハッシュ計算（Proof of Work）
ノードは、ブロックヘッダーのハッシュがネットワークのターゲット値（難易度）以下になるようなナンス（nonce）を探します。
ハッシュ計算は非常に計算コストが高いです。
ASIC（特化型ハードウェア）を使うのが一般的。
ブロック生成
ハッシュ値が条件を満たしたら、新しいブロックが生成され、ネットワークに伝播されます。
報酬の取得
マイナーはコインベーストランザクションを通じて報酬を得ます。
初期報酬は50 BTC（現在は6.25 BTC、4年ごとに半減）。
トランザクション手数料も報酬に含まれます。
ネットワークの合意
新しいブロックが有効であることが他のノードにより確認され、ブロックチェーンが更新されます。
感想
今回は基本的な仕組みと、テスト環境でもいいのでどのような感じでやり取りがされるので知れてよかった。
既存の仕組みを組み合わせて新しいものを作り出せるのはすごい。