Yuya

Yuya

@ogw_yuya

ちょビットコイナー

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の場合、ロックアップアドレスへ送金す

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を使えば良さそうですね。興味のある方はぜひプルリクをだしてみてください!

ペイメントチャネルを強制閉鎖できない、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

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

以前の投稿でライトニング決済における受信者の匿名性向上についての技術や現在策定中の仕様について紹介しました。その主な技術はルートブラインディング、オニオンメッセージ、オファーの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

話せばわかるご先祖様 purchased this article 4r1uou3wj

100

katakoto purchased this article 4r1uou3wj

100

まっく purchased this article 5lds4suyh

100

まっく purchased this article 7dubt0ixj

100

まっく purchased this article ne9kh3roo

100

Payment in Transit

-60600

culizusi purchased this article 4r1uou3wj

100

Anonymous tipped you

1000

tanakei purchased this article 4r1uou3wj

100

kojisan purchased this article 6jphw1e6d

100

Anonymous purchased this article yqymlagm2

100

Anonymous purchased this article vaal4lvtp

1000

Anonymous purchased this article 5lds4suyh

100

Anonymous purchased this article zykfinax7

100

Purchased this article hl243a3sc

-100

DNFYO purchased this article xlco5hfc6

1000

Purchased this article 1qxcv3kb2

-100

Purchased this article v1soshhco

-100

Purchased this article 8qr3natkw

-100

mi2 purchased this article vaal4lvtp

1000

Popular stories

LNノードの運用益はどれぐらい?パート1

1665

LNノードの運用益はどれぐらい?パート3

992

【Muun】ちょっと変わったライトニング搭載ノンカストディアルウォレット

985

Archives

2023-03
1posts
2023-01
2posts
2022-12
5posts
2022-11
2posts
2022-10
2posts
2022-09
1posts
2022-08
5posts
2022-07
4posts
2022-06
1posts
2022-05
4posts
2022-04
3posts
2022-03
2posts
2022-02
3posts
2022-01
2posts
2021-10
2posts
2021-09
5posts
2021-08
5posts
2021-07
9posts
2021-06
2posts
2021-05
4posts
2021-04
9posts
2021-03
11posts
2021-02
5posts
2021-01
4posts
2020-12
8posts
2020-10
2posts
2020-09
20posts
2020-08
4posts
2020-07
5posts
2020-06
10posts
2020-05
7posts
2020-04
10posts
2020-03
3posts
2020-02
3posts
2020-01
6posts
2019-12
6posts
2019-11
5posts
2019-09
1posts
2019-08
1posts
2019-07
1posts
2019-05
4posts
2019-04
7posts
2019-03
4posts
2019-02
5posts