Category: Bitcoin

### ペイメントの送信
AliceとBobでコミットメントトランザクションを作成する
ブロードキャストするとファンディングアウトプットが消費される

### ライトニングプロトコルの失効とペナルティのメカニズム
– 非対称コミットメントトランザクション
L self, remotoとする
L 資金を取り戻す時間が与えられる
– 遅延支払い
– 失効鍵
L ペナルティトランザクションを作成することでチャネルの資金を独り占めできる

### チャネルの状態遷移
commitment_signedとrevoke_and_ackの2つのメッセージを交換する

commitment_signed: channel_id, signature, num_htlcs, htlc_signature
revoke_and_ack: channel_id, per_commitment_secret, next_per_commitment_point

2of2マルチシグのトランザクションを保管していて、そのトランザクションを独占的に使う手段となり得たら、そのビットコインを事実上所有していることになる。
ペイメントチャネルは2人のチャネルパートナーが2of2マルチシグアドレスにファンディングを行うことによって確立される
ライトニングノードはノードの公開鍵によって識別
ネットワークアドレスはTCP/IPもしくはTCP/Tor

識別子は ノードID@address:port
2つのノード間の通信をLightning Peer Protocol for Channel Managementと呼ぶ
チャネルはメッセージの交換で確立される
open_channel, accept_channel, funding_created, funding_signed, channel_ready, channel_readyの6つの時系列
トランザクションが十分な数の承認を得た時点で、channel_readyメッセージを交換し、チャネルは通常の実行モードを開始

### マルチシグアドレス
2 2 CHCKMULTISIG
=> p2wshのアドレスとしてエンコードされる
トランザクションを作成し、署名するがブロードキャストしない
払い戻しトランザクションを作成する…ファンディングトランザクションのインプットを計算する

### funding_created
funding_txid
funding_output_index

### funding_signed
channel idはfunding transaction idとoutput indexのビットごとのxor

### funding_transactionをブロードキャスト
ブロックチェーンでの承認数がminimum_depthになるのを待つ。その後channel_readyメッセージで相手に送信

$ bitcoin-core.daemon -testnet -prune=1000
// 省略
2024-01-08T08:05:09Z UpdateTip: new best=000000000000000d549bd14334c241abfeb36cc5b6d04541af6061c0a21cdc92 height=2571591 version=0x20800000 log2_work=75.635907 tx=68073107 date=’2024-01-08T07:53:55Z’ progress=0.999999 cache=10.3MiB(35178txo)
2024-01-08T08:08:24Z Disconnecting outbound peer 15 for old chain, best known block =
2024-01-08T08:08:24Z New outbound peer connected: version: 70016, blocks=2571591, peer=17 (outbound-full-relay)

$ bitcoin-core.cli -getinfo -testnet
Chain: test
Blocks: 2571591
Headers: 2571591
Verification progress: 99.9999%
Difficulty: 38940120.97505151

Network: in 0, out 10, total 10
Version: 250100
Time offset (s): -2
Proxies: n/a
Min tx relay fee rate (BTC/kvB): 0.00001000

Warnings: Unknown new rules activated (versionbit 28)

progressが99.9999%で待受状態となる
outbound-full-relay隣nodeが待機しているのね。
なるほど〜

LNの仕様はBOLT(basis of lightning technology)に定義
LNのプロトコルスタックは5つの層になる

– ネットワーク接続層
TCP/IP, オーバーレイプロトコル(Tor v3), 暗号トランスポートプロトコル

– メッセージング層
negotiate, message format, message field

– P2P
message

– routing
ノード間でのペイメントのルーティングをエンドツーエンド方式でアトミックに行う

– ペイメント

Bitcoin CoreとRegtest
ライトニングノード実装のほとんどは、正常に動作するためにビットコインのフルノードにアクセスできなければならない。

### regtestモード
テスト用にシミュレートされたビットコインブロックチェーンがローカルに作成される
10秒ごとに新しいブロックを6つずつマイニングするよう設定されている
RPC(Remote Procedure Call)はポート18443で提供されており、ユーザ名regtest, パスワードregtestでRPC呼び出しにアクセスできる
マイニングされたビットコインはブロック数が100を超えるまで使えない制約がある

$ sudo docker pull lnbook/bitcoind
$ sudo docker run -i –name bitcoind lnbook/bitcoind –platform linux/amd64/v8
WARNING: The requested image’s platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
exec /usr/local/bin/bitcoind-entrypoint.sh: exec format error

m1に対応していない？
LNには、c-lightning, LND, Eclairなど様々なプロジェクトがある。

$ bitcoin-core.daemon -testnet -prune=1000

$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 459M 0 459M 0% /dev
tmpfs 476M 0 476M 0% /dev/shm
tmpfs 476M 49M 427M 11% /run
tmpfs 476M 0 476M 0% /sys/fs/cgroup
/dev/vda2 25G 21G 2.3G 91% /
/dev/loop0 116M 116M 0 100% /var/lib/snapd/snap/bitcoin-core/145
/dev/loop2 56M 56M 0 100% /var/lib/snapd/snap/core18/2790
/dev/loop1 41M 41M 0 100% /var/lib/snapd/snap/snapd/20290
tmpfs 96M 4.0K 96M 1% /run/user/1000

100GBに拡張したはずだけど、vda2は25Gのままだな…
ただ、testnetの場合はかなり早い

$ bitcoin-core.cli -getinfo -testnet
Chain: test
Blocks: 1579532
Headers: 2571357
Verification progress: ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░ 77.2822%
Difficulty: 1

Network: in 0, out 10, total 10
Version: 250100
Time offset (s): 0
Proxies: n/a
Min tx relay fee rate (BTC/kvB): 0.00001000

Warnings: (none)

$ pwd
/home/alma/snap/bitcoin-core/common/.bitcoin

$ ls
anchors.dat chainstate mempool.dat testnet3
banlist.json debug.log peers.dat wallets
blocks fee_estimates.dat settings.json

banlist.dat: 禁止ノードのIPアドレス、サブネットのリスト。
bitcoin.conf: Bitcoin Coreの設定ファイル。接続するのがmainnetかtestnetかなどを指定することができる。自動生成されず、自分で作成する必要がある。
bitcoin.pid: bitcoindをデーモンで起動した際のPIDファイル。
blocks/blk000??.dat: ブロックの生データ。ウォレット内の欠落しているトランザクションを再スキャンする際や、同期中の他のノードにブロックデータを提供する際などの利用される。
blocks/rev000??.dat: blocksディレクトリ内に格納されている、undoデータ。
blocks/index/*: 既知のブロックのメタデータやその格納場所の情報が格納されたLevelDBのDB。
chainstate: 現在未使用のトランザクションアウトプット（UTXO)とそのトランザクションのメタデータをコンパクトにしたLebelDBのDB。受信したブロックやトランザクションを検証するために利用される。
database: Berkeley DBのジャーナリングファイルが格納されるディレクトリ。
db.log: ウォレットデータベースのログファイル。
debug.log: Bitcoinの詳細なログ。
fee_estimates.dat: 手数料と優先順位を予測するための統計。プログラムのシャットダウン時に保存され、起動時に読み込まれる。
mempool.dat: メモリプール内のトランザクションのダンプ。
peers.dat: 再接続を容易にするためのピア情報用のストレージ。ビットコイン専用のフォーマットを使用している。
wallet.dat: 鍵やトランザクション、メタデータ、オプション情報が保存されるBerkelay DBのデータベースファイル。
.cookie: セッションRPC認証クッキー。クッキー認証が使用されている時に書き込まれ、シャットダウン時に削除される。
onionprivatekey: キャッシュされたTor匿名通信サービスの秘密鍵。
testnet3: testnetモードでbitcoindを起動した際のデータ。
regtest: regtestモードでbitcoindを起動した際のデータ。regtestディレクトリを削除してBitcoin Coreを再起動すると、新しいregtest環境になる。
.lock: Berkeley DBのロックファイル。

bitcoin.confはここに書くのね。

1. ゴシッププロトコルを使ってトポロジー情報を伝播する広い範囲のp2p
2. チャネルパートナー間のペイメントチャネルのネットワーク
ピア間の通信はLNメッセージが使われる
Noise Protocol Frameworkを使って暗号化される

### ビットコインとの比較
LNでは支払い受取人がインボイスを作成する。インボイスは1
ライトニングペイメントはBTCのトランザクションに相当
UTXOは必要なく、ペイメントによって残高が更新されて再配分　AMPやMPPを使うと複数のライトニングをまとめられる
マイニングはないがルーティング手数料が課される
ライトニングネットワークのリソースはchannel liquidityとchannel connectivity
LNはmillisatoshi

ソースベースのpthfindingは有効なソリューションの一つ
十分な流動性を持つパスが見つかるまで、様々なパスを反復的に試す
チャネルパートナーであれば、経路探索は難しくはない

### オニオンルーティング
オニオンルーティングプロトコルを使用する SPHINX Mix Formatと呼ばれる
そのノードだけが複合できる層を使って暗号化するのを繰り返す
誰が支払いを開始・行うかをノードが知ることができない
オニオンのホップは最大26、HMACで暗号化

### ペイメント転送アルゴリズム
update_add_htlcメッセージを送信する

### p2pゴシッププロトコル
チャネルアナウンスはp2pのgossip protocolによる伝播される
channel_announcementメッセージでピアに公表
node_announcementメッセージで公表する目的で使われる

支払人から受取人までのパスを見つけ出すことをpathfindingと呼び、そのパスを使ってペイメントを転送することをルーティングと呼ぶ

pathfindingはソースベースプロトコル、支払いのルーテインングにオニオンルーティングと呼ぶ

インボイスは支払い指示書
ペイメントID(ペイメントハッシュ)、受取人、金額、オプションなどが含まれる
通常インボイスはbech32エンコードかQRコードとしてエンコードされる
インボイスには請求金額と受取人の署名が含まれる。支払い人はこの署名を使って公開鍵(ノードID)を取得する
LNはインボイスに基づきペイメントを送信
有効期限を設定することもできる

### ペイメントハッシュ
ランダムな数字r
H = sha256(r)