BIP157とBIP158の触り

以前触れた通り、NeutrinoはBIP157とBIP158の参照実装となっている。注意しないと行けないのは、この２つはdraft段階であり、まだ議論中のものであること。

ってか、Olaoluwa Osuntokunってよく名前を聞くroasbeefだったんだ。Lightning LabsのCTO。golang使いみたいだから、そういう意味でも注目しよう。

気になるのはBIPで受理されていない実装を Neutrinoが行っているということは、現状この支払いができるのはNeutrinoのみだということだ。こういう場合ってどうなるんだろう。っていうかそもそも、BIP化する場合とかってに実装しちゃう場合ってどう違うの？

BIP157 Client Side Block Filtering

SPVに利用されるbloom filterの持つ課題である、privacyとdos攻撃のリスクを軽減させるために、クライアントサイドでフィルタリングを実施する提案だ。

だから、フルノード側もアップデートが必要で、しかも下位互換性はない。
現在実装されているのはNeutrinoだけだが、bitcoindではいつ頃になるのだろうか。普通、bitcoindに参照実装がなされるのはいつ頃なんだろう。draft段階でやられるのか？とか考えて、

BIPの承認フロー

Acceptedの段階ではいつFinalに移行するかわからないレベルなので、少なくともこの段階では出来上がっていないとまずい。とするとdraft段階でかなり実装されているのがふつうなのかな？

BIP158 Compact Block Filters

実質的には、BIP157とBIP158が合体して初めて新しい　SPVの形が完成する。ここでは、ブロックデータのコンパクトなフィルタの構造について定義している。
BIP-37のBloom Filterの代替として提案されたフィルタ構成は、圧縮にゴロム・ライス符号を使用することでフィルタサイズを最小限に抑える。

なぜ既存のbloom filterではだめなのかというと、　こっちでは、各SPVの識別情報を統一してごちゃまぜにする感じだからだと思う。

だけど問題なのは、full node側へのメリットの少なさ。これはpeer serviceのBIPになるわけだけど、承認条件である1%以上のノードが採用っていうのは結構ハードルが高い気がする。それこそneutrino/lndが頑張るっていうシナリオを想定してしまう。