#

ビットコイン

(8 articles)

LIGHTNING_OVERWRITES_01制作ノート

## はじめに 《LIGHTNING_OVERWRITES_01》は、ビットコインのLightning Networkを通じた送金が、写真の上に光の痕跡として現れるオンラインLIVE作品です。 鑑賞者がビットコインを送ると、その送金をきっかけに、ロボットがリアルタイムでB0サイズの写真プリント上に⚡マークを描き込みます。送金という不可視の行為が、物理的な描画へと変換され、写真を少しずつ上書きしていきます。 ![スクリーンショット 2026-07-05 11.57.49](https://npub1vz6gesknjtz7t9vm2j0vdnsexmw4tan79lcsgpy5kh80683e8xkq2z858e.blossom.band/d2e69c064d2ea2b17b225b08b7eea353fae8daf7a77a0aba7869d75ee628f20a.png) 配信スケジュールは下記の通りです。 7/5 Sun 11:00 / 13:00 / 18:00 / 21:00 7/6 Mon 21:00 7/7 Tue 11:00 / 13:00 / 18:00 / 21:00 https://lightning-overwrites.steganography.tokyo/ ## ステガノグラフィーについて 私たちSTEGANOGRAPHY TOKYOの名前に含まれる「ステガノグラフィー」とは、ある情報の中に別の情報を隠す技術のことです。 本作では、イスラエルで撮影された写真の撮影地を、地名として直接表示していません。代わりに、座標のかたちで作品ページ上に小さく記しています。座標としてだけ残されたその場所は、作品の中に「隠された情報」として静かに埋め込まれています。 2026年にこの写真に光を描いていく行為、そして上書きする行為がなぜ必要なのか、これらが本作《LIGHTNING_OVERWRITES_01》のコンセプトです。 ## 作品の構造 本作では、写真、Lightning送金、Webページ、LIVE配信、ロボット描画を接続しています。 鑑賞者は、作品ページ上に表示された送金リンクから、ビットコインの最小単位であるsatを送ることができます。着金が確認されると、システムはその送金をトリガーとして認識し、制作環境側のロボットが写真の上に⚡マークを描きます。その様子はLIVE配信を通じて公開され、鑑賞者は自分の送金が写真の上に痕跡として現れる過程を見ることができます。 流れは以下の通りです。 鑑賞者がLightning Networkで21 / 210 / 2100 satsを送金 ↓ LNbitsが着金を記録 ↓ 作品ページ上の合計sats数や履歴が更新される ↓ 制作環境側のMacが着金を確認 ↓ ロボットが写真の上に⚡マークを描画 ↓ LIVE配信で共有 ## Lightning Networkとsat Lightning Networkは、ビットコインをすばやく少額送金するための仕組みです。sat、またはsatoshiは、ビットコインの最小単位です。 1 BTC = 100,000,000 sats です。 2026年7月5日現在のレートでは、おおよそ 21 sats = 約2円 210 sats = 約21円 2100 sats = 約210円 となっています。 satsの数によって描かれる⚡マークの大きさが変わります。 ## Webページと配信構成 作品は、オンライン上の作品ページを入口として公開しています。 作品ページでは、LIVE配信、送金リンク、着金履歴、合計sats数、描画数などを表示します。鑑賞者は、ページを見ながらLightning送金を行い、その送金がロボットの描画へと変換される過程を確認できます。 作品ページは、LIVE配信と決済導線を同じ画面上に配置することで、鑑賞、参加、記録がひとつの流れとして体験できるように設計しています。 ロボットが動くのは、原則としてLIVE配信中のみです。配信していない時間帯に送金があった場合は、リアルタイム描画の対象外としています。 ## LNbitsを使った決済導線 決済部分には、LNbitsを使用しています。 https://lnbits.com/ LNbitsにはLNbits SaaSというサービスがあり、1時間単位で利用することができます。またLightning払いを選択することが可能です。 LNbitsのPay Linkは、固定された送金導線を用意できるため、展示中の運用に適していました。鑑賞者は複雑な設定を行う必要がなく、Lightningウォレットから指定額を送るだけで作品に参加できます。 ## Zap.streamとYouTube 制作初期には、LIVE配信とLightning送金の連携手段として、非中央集権型ライブ配信サービスZap.streamの利用も検討しました。 https://zap.stream/ Zap.streamは、Nostrと呼ばれる非中央集権型のSNSとLightning Networkを組み合わせた配信プラットフォームで、視聴者が配信中にZapと呼ばれる投げ銭(Lightning)を送ることができます。 特徴は、配信者が自分でサーバー代を負担する点で、これによりプラットフォームによる中抜きがありません。そのサーバー代もとても安いです。(1分1sat程度、24時間配信しても0.9ドル程度) しかし、実装の過程では、管理画面が不安定になるなど、安定した運用が難しい場面がありました。そのため最終的には、Zap.stream上で完結させるのではなく、YouTubeとLNbitsのPay Linkを中心にした構成へ切り替えました。 ## 全体構成 場所/役割 LNbits(クラウド) Lightning 着金の受け取り・履歴の記録 VPS(公開サイト) Pay Link / QR、着金履歴の表示(Webhook) 会場 Mac 着金監視 → Root 描画のみ 鑑賞者の支払い → LNbitsに着金 → MacがAPIをポーリング → ロボットが写真プリント上に⚡を描く。 描画には、制作環境側のMacと接続したiRobot社の教育用ロボットを使用しています。Mac側では、LNbitsの着金履歴を定期的に確認し、新しく着金があった場合に、その着金を描画トリガーとして扱います。 ## AI Agentとの制作 本作のシステム制作には、Cursor上のAI Agentを使用し、基本的にはAutoモードで進めました。STEGANOGRAPHY TOKYOのメンバーには暗号などに詳しいエンジニアもおりますが、今回の制作は非エンジニアのみで完結しています。 この作品の構想自体は1年ほど前からありましたが、当時、非エンジニアのみで納得できるものを構築するのはまだ難しい状況でした。 その意味で、本作はLightning Networkやロボットだけでなく、AI Agentによって制作可能になった作品でもあります。 ## まとめ 《LIGHTNING_OVERWRITES_01》は、ビットコインのLightning送金を、写真の上に現れる光の痕跡へと変換する作品です。そのコンセプトはただビットコインをツールとして扱うものではなく、この写真がなぜ上書きされる必要があるのかを問う作品です。 #Bitcoin #LightningNetwork #BTC #ビットコイン #Photography #Art #写真 #アート #反戦

ビットコインノードにポリシーがある理由、および標準ポリシーを設けて何がしたいのか?

各ノードにポリシーがある理由 → ノードの資源(CPU、帯域、メモリ)を守り、無駄な処理を避けるため なぜポリシーがコンセンサスルールより厳しいか 1.資源の節約 コンセンサスルールは「最終的に有効かどうか」の基準だが、全トランザクションをいちいち検証して中継すると資源が枯渇する。 ポリシーで「最初から弾く」仕組みが必要。 2. ネットワーク健全性の維持 手数料が低い、複雑すぎる、標準でないスクリプトのトランザクションが大量に流れると、全体のネットワークが重くなる。 これを防ぐためにノードは独自のポリシーで中継制限。 3. 開発の柔軟性 ポリシーはソフトウェアアップデートで柔軟に変えられるが、コンセンサスルールは変えるとハードフォークの危険がある。 ポリシーを厳しくすることで、安全に新しい制限を試すことができる。 --- 標準ポリシーの意味は何か? ノードオペレーターは自分でbitcoindの設定やコードを書き換えて独自のポリシーを使える。 理論上ポリシーは「任意」で、標準ポリシー(Bitcoin Coreが提供するポリシー)は単なるデフォルト値。 ただし、標準ポリシーには以下の大事な意味がある。 1. ネットワークの互換性を保つ基準 みんなが全く自由なポリシーを使うとトランザクションの伝播効率が落ちる。 標準ポリシーは「大多数のノードに中継される最小基準」を提供し、それを守ればネットワークに流せるという共通の期待値になる。 2. 開発・サービスの指針 ウォレット開発者やサービス提供者(取引所・支払いサービスなど)は、「標準ポリシーに準拠したトランザクションを作れば十分」という前提で開発できる。 もし標準がなければ全ノードの個別ポリシーを調査しないと流れるトランザクションを作れなくなる。 3. コミュニティの合意形成の場 標準ポリシーはBitcoin Coreの開発・議論で決まる。ここで新しい制限や緩和を入れれば、まずポリシーレベルで試せる。 問題がなければ、将来のコンセンサスルールに昇格させる議論の土台になる。 つまりデフォルトだけど重要。 確かに標準ポリシーは技術的には「デフォルト値」にすぎないが、実際にはネットワークの安定・互換性・開発指針の柱として重要な役割を果たす。 --- ビットコインノードにおける「無駄な処理」というのは、主に次のようなものを指す。 1. 承認される見込みのないトランザクションの検証 例: 手数料が極端に低く、マイナーが絶対にブロックに入れないようなトランザクション → これをいちいち署名検証したり、メモリプールに載せるのはCPU・RAMの無駄。 2. 明らかに標準外のスクリプトや形式の検証 例: 極端に複雑・非標準なスクリプト(non-standard script) → コンセンサス的には有効だが、ネットワークの他ノードが中継しないため、無駄な伝播になる。 3. スパム的な大量トランザクションの処理 例: 攻撃者が極小手数料のトランザクションを大量に送り、メモリプールを膨張させる場合 → メモリやディスクI/O、帯域の消費が無駄になる。 4. 明らかに無効なブロックの詳細検証 例: サイズが大きすぎるブロック、難易度条件を満たさないブロック → 早期に弾かないと、全トランザクション検証や署名検証で計算資源を浪費する。 これらの無駄な処理は、ノードの CPU時間・メモリ・ディスクI/O・帯域 を消耗させ、最悪の場合は DoS攻撃(サービス妨害攻撃) に悪用される。 そこでポリシーによって、最初の受信段階、または中継段階でそもそも検証・保存・転送しないように制限する。 まとめると、「無駄な処理」とはネットワークの大勢に受け入れられず、ブロックに取り込まれないトランザクションやブロックにノード資源を使うこと。 --- 無駄な処理かどうかは、単に「ポリシーで禁止されているか」で決まるわけではない。 本質的には次の2つで判断される 1. ノードの資源(CPU、メモリ、帯域、ディスク)を過剰に使うか 2. 他のノード・ネットワーク・マイナーに受け入れられる見込みがあるか 将来のBitcoin CoreのバージョンでOP_RETURNの出力数制限やデータサイズ制限が撤廃されたとする。 この場合標準ポリシー的には通るので、中継・保存されやすくなる。 しかし、他のノードやマイナーが追随しなければ意味がない。大量に流せばやはりDoS・スパム扱いされ、無駄な資源消費になる。 最終的には、ネットワーク全体の運用実態。 標準ポリシーの撤廃だけでは、「無駄な処理ではない」とは断定できない。 実質的な「無駄な処理」の判定は、技術的制約+経済的・運用的現実のセットで決まる。