ソフトウェアエンジニアの技術ブログ：Software engineer tech blog

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)

チャネルパートナーとは2つのノード間の金銭関係、2of2マルチシグの暗号プロトコルによって管理(自分と相手)
チャネルの残高がエンコードされ、その残高をどのように分配するかが定義される
トランザクションシーケンスのトランザクションはスプリクト言語を使う
チャネルを開いた時にコミットされるビットコインの量
チャネル経由で同時に送信できる未実行・実行中のルーティングペイメントの数も制限される
ビットコインブロックチェーンに記録されるのは最終残高のみ

### ファンディングトランザクション
1人がマルチシグアドレスにbitcoinを送金することでペイメントチャネルに資金を預ける
これをchannel capacityと呼ぶ

### チャネルの開き方
2つの公開鍵を使って2of2マルチシグアドレスを作成
払い戻しトランザクションはコミットメントトランザクションと呼ばれる

1. open_channelメッセージでBobに通知
2. accept_channelメッセージでAliceに送信
3. pubkey pubkey 2 CHECKMULTISIGでトランザクションを作成
4. funding_createdでBobに送信
5. コミットメントトランザクションを作成
6. Bobが funding_signedメッセージでAliceに返す
7. 署名交換後にAliceがブロードキャスト

### 古い状態を使った不正
古いコミットメントトランザクションが送信された場合は、罰を与えることができるように作られれている
失効のメカニズム:timelock delayとrevocation secretがペイメントにある
新しいコミットメントの際に、古いコミットメントトランザクションを失効させる
※失効シークレットの管理と格納はLNの最も複雑な部分の1つである

### チャネルを公表・クローズ
チャネルを公表するとルーティング手数料を獲得できる
チャネルを閉じるときはトランザクション手数料がかかる
クローズには相互クローズ、強制クローズ、プロトコル違反などある

LNを使うには、ニーズに合ったLNウォレットを選ぶ必要がある
L Eclairウォレットを選択する

ライトニングネットワークノードはウォレットである
他のライトニングノードとP2P方式で通信しなければならない
LNはbitcoin nodeにアクセスし資金を保全する必要がある

ライトニングエクスプローラ
https://1ml.com/
その他にもACINQ, Amboss Space, Fiatjaf, hashXPなどLNエクスプローラがある

### ライトニングウォレット
keystore: secret keyを保持
Lightning Network Node
Bitcoin node
database map: ノードとチャネルのマップ
channel manager: LNチャネルを開閉できるコンポーネント
close-up system: チャネルのパスを調べるコンポーネント
※鍵の管理を外部に委託するウォレットをcustodial walletと呼ぶ。鍵をどのように管理するかでウォレットを選択する。またLN Walletが使うのはfull nodeか第三者のnodeかなどを見極める必要がある
Lightweight, Noneなどはcustodial walletになる。自己管理型かどうかを選択する

Neutrino: ビットコインノードを実行しないwallet, neutrinoプロトコルを使ってアクセス
Electrum: ビットコインノードを実行しないwallet