ビットコインVSイーサリアム

Bitcoinに任意データを書き込むOrdinals

Bitcoin上に任意データを書き込む方法にはOP_RETURNを使う方法がありますが、これは80バイトの制限があります。この制限を突破しブロックサイズまでデータを書き込む方法が提案されました。 その方法は、インプットであるWitness領域を使います。Taprootが導入される前もこのWitnessを使うことで任意のデータを埋め込むことはできましたが、10,000バイトの制限がありました。しかし、Taprootの導入でこの制限が適用されないことになり、実質ブロックサイズの4MBまで任意データを書き込むことが可能になりました。 Ordinalsの場合、以下のルールに沿ってデータを書き込み、読み取ることになります。 Bitcoinのブロックチェーン上に任意データが書き込まれ

Swap-in-Potentiam 備忘録

LNへのオンボードにはチャネル開設が必要であったり、チャネルマネジメントのためにオンチェーンとオフチェーンの資金交換をしたりと、L2技術とは言え、なにかとオンチェーン送金が必要になる場合があります。オンチェーン送金をする場合、0承認TXを許容することも可能ですが、基本的にはブロック承認を待つことが望ましいとされています。Diamond Swapでもある一定の条件を満たすことで0承認を許容していますが、できることなら避けて通りたい道です。 この問題を解決し得るある提案がLNメーリスで紹介されていました。本提案では、0承認でもトラストレスにSwap-inができるというものです。 ユーザーのシナリオとしては、まずウォレットからアドレスを生成して、そこへBTCを送金します。これは取引所からの出金であったり、第三者からの支払いであったりなんでも構いません。そして後日、ユーザーはLN決済でコーヒーを買おうとします。この時、ウォレットにチャネルがない場合はチャネル開設が必要で、チャネルがあってもアウトバウンドキャパシティがない場合はSwap-inをしてウォレットへBTCをチャージしたりする必要があります。この際、オンチェーン送金が発生するので、ブロック承認を待つ必要があります。 ここで、ウォレットから生成するアドレスをある特別なアドレスへ少し変換してあげます。そうすることで、チャネル開設やSwap-inをする際にブロック承認を待たずしてトラストレスにウォレットへBTCを送金することが可能になります。 その特別なアドレスは、2つのブランチによる消費条件で構成されています。1つはAとBのマルチシグを必要とするブランチで、もう1つはAの署名と相対的なタイムロック（OP_CSV）が掛けられているブランチです。このアドレスへ送金された資金であれば、Swap-inを0承認で安全に行うことができます。 通常のSwap-inの場合、AがBが生成したロックアップアドレスへオンチェーン送金をして、その送金が承認されるとBがSwap-inを開始します（AへLN送金をする）。そしてAがプリイメジを公開することで、Bがそのプリイメジを使いロックアップアドレスから資金を回収してSwap-inが完了します。もしここで、AがRBFによるロックアップアドレスへのオンチェーン送金TXをキャンセルしてしまうと、Bはロックアップアドレスからの資金回収ができなくなります。そのため、BはそのTXが含まれるブロック承認を待つ必要があるわけです。 Swap-in-Potentiamの場合、ロックアップアドレスへ送金す

P2TRアドレスの復習🥕

昨年末にビットコインのソフトフォークが完了して早一年。そのソフトフォークでシュノア署名やP2TRアドレスなどが導入されましたが、まだまだウォレットや取引所などの対応が追いついていないのが現状です。今回はP2TRの復習も兼ねて、btcdevを使いテストネットで検証してみました。このツールはregtest用なので、テストネットで使うにはコードを少し変更（こことここ）してコンパイルしてください（--enable-dangerousを付けたほうがあとあと良さげ）。そして、こちらの手順に沿って生成したP2TRアドレスが以下になります。 tb1p3nea55z3wrg0cqxhmaqc849zhy3hp3c742q7rk0u2zfswglsn0fs3sc06m P2TRアドレスには大きく二つの使用方法があり、Key pathとScript pathです。Key pathは署名のみで消費できる方法なので面白くありません。なので、今回はScript pathを使って消費してみました。上記のP2TRアドレスは以下の図のように３つのスクリプトで構成してあります。P2TRアドレスの構成や仕組みはこちらの記事が分かりやすいので興味のあるかたはどうぞ。 <img src="https://s3-ap-nor

LNDgのFailed HTLCsに足りないもの

以前の記事で、ルーティングエラーによる機会損失について解説しました。その中で、ルーティングエラーには大きく分けて2種類あり、自ノードが原因のものと後続ノードが原因のものがあることに触れました。具体的にはLNDの場合、link_fail_eventが自ノードに原因があり、forward_fail_eventが後続ノードに原因があることを示しています。これらのデータはstream-lnd-htlcsというツールを使うことで取得でき、そのデータ解析ツールはMarimoxさんの記事で紹介されています。 LNDgにも似たような機能があり、ダッシュボードの「Failed HTLCs」から確認ができます（詳細は赤かぶとさんの記事を参照）。しかし、このエラー内容は自ノードが原因のものだけしか保存されません。本来は後続ノードのルーティングエラーも取得するべきで、エラーが頻発しているチャネルは閉じたほうがいいかもしれません。そのデータを取得するには、forward_fail_eventを取得する必要がありますが、これはルーティング金額等が含まれていないので、forward_eventから取得する必要があります。そのキーにincoming_channel_id:outgoing_channel_id:incoming_htlc_id:outgoing_htlc_idを使えば良さそうですね。興味のある方はぜひプルリクをだしてみてください！

ビットコインはいいよね

ビットコインだけでも追うのが大変だし興奮するし楽しいよね！ DLC Channel Tapleaf Channel Covenants Mercury Wallet (State chains) Blinded Path/Onion messages

コベナンツとSIGHASH_ANYPREVOUTを活用したTapLeaf Channel

Adopting Bitcoinのあるセッションで紹介されていたChannel Addresses他についての備忘録。 登壇者は先月LNDの脆弱性を見つけて巨大なトランザクションを放火したBurakさん。トーク内容は以下の3つ。 Channel Addresses TapLeaf Channels Factory Swaps Channel Addessesに関してはこちらの記事に詳細が記載されていますが、他の仕組みについては資料が見つけられませんでした。 Channel Addresses Channel Addressesは特別なビットコインアドレスで、第三者に渡して支払いなどに使うことができ、第三者がそのアドレスへ送金すると、自分と予め指定したLSPとの間でペイメントチャネルを開設することができるものです。ペイメントチャネルは2者間で対話的に開設する必要がありますが、非対話

コベナンツを活用した自動マーケットメーカー

Uniswapなどで一世を風靡した流動性プールの自動マーケットメーカー（AMM）がついに、ビットコインのサイドチェーンLiquidでも可能になったようです。イーサリアムとは違いビットコインはチューリング完全ではないので、複雑なスマートコントラクトを実装することはできません。Liquidも同様なのですが、ビットコインには無いいくつかの機能があります。その機能の1つにコベナンツというトランザクションを制御する機能（正確にはOPコード）があり、これを活用することでAMMを実現しているみたいです。興味のある方はMarina walletというブラウザ拡張をインストールして使ってみてください。 メインネット：https://beta.bitmatrix.app テストネット： https://multi.bitmatrix.app AMMを実現しているコベナンツの概要はこちら。ただ、この資料だけでは理解できなかったので、もう少し詳細に調べてみよう。

ペイメントチャネルを強制閉鎖できない、CPFPもできない

昨日あたりからビットコイン送金が大量に発生しています。それに伴い送金手数料も高騰しており、手数料が14.5 sats/vByte以下のトランザクションはmempoolから排除されています（引用元はこちら。mempoolのサイズは各ノードごとに異なる）。手数料が低いトランザクションを送信後マイニングされずにmempoolに停滞する場合、RBFやCPFPで手数料を引き上げることができます。ライトニングネットワークではCPFPを使ってタイムセンシティブなHTLCを素早くマイニングさせるような仕組みを取っています。 ライトニングネットワークのペイメントチャネルは、両者が署名をすることで協調的にチャネルを閉鎖します。しかし、相手がオフラインになっている時など協調的にチャネル閉鎖できない場合は、事前に署名しておいたcommitment_txを送信することで一方的にチャネルを強制閉鎖させることができます。 LNDのデフォルトではこのcommitment_txの手数料が10 sats/vByteとなっています。そのため、mempoolが混雑している現時点でこのトランザクションを送信してもネットワークを伝播することができず、チャネルを強制閉鎖することができません。LNのペイメントチャネルには手数料を引き上げるためにアンカーアウトプットがついているので、これを使ってCPFPをさせることができますが、そもそもcommitment_txがmempoolに存在しない状態ではCPFPができず、それが問題だと指摘されています。

mempoolfullrbf、その論点と結末

現在、Bitcoin Coreにmempoolfullrbfという機能を追加する話題でちょっとした論議が繰り広げられています。 このmempoolfullrbf（以下fullrbfと称す）の説明には、まずはRBF（Replace by Fee）について理解する必要があります。基本的にビットコインの送金は取り消しやキャンセルができません。しかし、RBFという仕組みはブロック承認前（言い換えるとmempoolに存在する場合）であれば、送信した取引データを手数料を高くした取引データで置換できるというものです。このRBFという仕組みはBIP125に準じて実装されていて、送信する取引データに「この取引データはRBFを許容するものですよ」というシグナリングをする必要があります。このシグナルがない取引データに対してはRBFは使えません。 fullrbfは、取引データにシグナルがなくてもRBFを許容する機能で、デフォルトではオフになっています。そもそもシグナルを付与すればRBFできるのに、なぜfullrbfが必要なのか、その動機とはなんでしょうか。シグナリングによるRBFではLNやDLCなど1つのUTXOを共有するコントラクトの場合に問題が発生する可能性があります。2者間によるコントラクトの場合、悪意ある相手がシグナリングせずに取引データをブロードキャストすることができてしまいます。これはPinning攻撃と呼ばれる攻撃手法の一種で、最悪の場合資産を失う危険性があります。fullrbfが導入されればシグナリングがなくてもRBFが可能となり、不正なデータを正しいデータへ置換でき、上記の攻撃を回避することができます。 一方、fullrbfは0承認をサポートしているサービスに問題が生じるかもしれません。例えば、店頭で商品を購入し、店を出てから支払い先のアドレスを自身のアドレスへ変更する、という不正ができてしまいます（店頭なので顔がバレてしまいますが笑）。現状はシグナリングされていない送金であれば、RBFされることはないので0承認を許容してもさほど問題はありません。しかしfullrbfが導入されるとシグナリングがなくても支払いがキャンセルできてしまうので、小売店が抱えるリスクが上がってしまいます。 このようにRBFにはメリットデメリットがありますが、mempoolfullrbfの実装はすでに終わっており、Bitcoin Coreにマージされました。 しかし、このマージ後に再度fullrbfの賛否を問う議論がはじまり、この機能を削除しようという<a href="https://github.com/bi

IMMORTANとは

IMMORTANは、もともとBitcoin Lightning Walletの開発者Anton氏がLNBIGのサポートで開発を開始していて、たしかトランポリンやプライベートチャネル経由でのルーティングとかの実装も進めてたはず、そのスポンサーがZEBEDEEになってLNTXBOT等の開発者Fiatjaf氏も参画して開発されたみたい。 大元はNBD(No Big Deal)というZEBEDEEのプロジェクトで、その傘下でOBW(Open Bitcoin Wallet)やIMMORTANが開発されているみたい。 LDKよりIMMORTANの方がモバイル開発はしやすいのかもしれない。

オニオンメッセージと非同期ペイメント

以前の投稿でライトニング決済における受信者の匿名性向上についての技術や現在策定中の仕様について紹介しました。その主な技術はルートブラインディング、オニオンメッセージ、オファーの3つで、それらを仕様確定前に実験的に実装していたのがCore-lightningとEclairで、それを追随するかのようにLDKがオニオンメッセージをサポートしたことが明らかになりました。 <iframe style="position: static; visibility: visible; width: 550px; height: 576px; display: block; flex-grow: 1;" id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" allowfullscreen="allowfullscreen" class="" title="Twitter Tweet" src="https://platform.twitter.com/embed/Tweet.html?dnt=true&embedId=twitter-widget-0&features=eyJ0ZndfdGltZWxpbmVfbGlzdCI6eyJidWNrZXQiOlsibGlua3RyLmVlIiwidHIuZWUiLCJ0ZXJyYS5jb20uYnIiLCJ3d3cubGlua3RyLmVlIiwid3d3LnRyLmVlIiwid3d3LnRlcnJhLmNvbS5iciJdLCJ2ZXJzaW9uIjpudWxsfSwidGZ3X2hvcml6b25fdGltZWxpbmVfMTIwMzQiOnsiYnVja2V0IjoidHJlYXRtZW50IiwidmVyc2lvbiI6bnVsbH0sInRmd190d2VldF9lZGl0X2JhY2tlbmQiOnsiYnVja2V0Ijoib24iLCJ2ZXJzaW9uIjpudWxsfSwidGZ3X3JlZnNyY19zZXNzaW9uIjp7ImJ1Y2tldCI6Im9uIiwidmVyc2lvbiI6bnVsbH0sInRmd19jaGluX3BpbGxzXzE0NzQxIjp7ImJ1Y2tldCI6ImNvbG9yX2ljb25zIiwidmVyc2lvbiI6bnVsbH0sInRmd190d2VldF9yZXN1bHRfbWlncmF0aW9uXzEzOTc5Ijp7ImJ1Y2tldCI6InR3ZWV0X3Jlc3VsdCIsInZlcnN