chaintope / bitcoinrb

The implementation of the bitcoin protocol for ruby.
MIT License
61 stars 19 forks source link

Features/bloom filter #12

Closed Yamaguchi closed 6 years ago

Yamaguchi commented 6 years ago

spvの起動時にウォレットのアドレスを読み込んでbloom filterに追加する必要があるかと思いますが、そこは今回は実装していません。現状、アプリ側からspv.filter_load -> spv.filter_addで追加することはできます。

Yamaguchi commented 6 years ago

すみません、一部誤りがありますので(filteraddのあとにgetdataしているところとか)後ほど修正します。

azuchi commented 6 years ago

はい。[WIP]と記載されてたのでマージしない方が良いのかと思ってました。マージしてよくなったら教えてください。

Yamaguchi commented 6 years ago

testnetで動作確認して、 filter_addしたアドレスやtxidを含むブロックが生成された場合、merkleblockで通知される(パターンがある)のは確認できましたが、ピアによって動作がことなり、ブロック生成時に

の2種類の動作が認められました。filter_load等の呼び出しかたに問題ないか確認中。

azuchi commented 6 years ago

ピアの挙動の違いは実装やバージョンに起因するものですか? 接続先のピアの情報はgetpeerinfoすると確認できます。

Yamaguchi commented 6 years ago

testnetで繋いだ時のメッセージのやり取りですが、

primaryのピアのみでgetheadersを送信しているのは、同じブロックを複数回受信しても意味がないからという理解。 filter_load, filter_addした時にprimaryの動作が変わらない(merkleblock,txを受信しない)のはピアが1つだけ(regtestとか)の場合には問題となりそう。 ピアが複数の場合は、ブロックヘッダーの情報はprimaryから取得/更新し、filter_load/addしたtxの情報はprimaryでないピアから取得するという動作仕様でよいか?(ピア数=1の場合の問題は残る)

ピアの挙動の違いは実装やバージョンに起因するものですか?

versionはすべて70015、subverはほとんど0.15.1で、0.14.1や0.15.0.1が時々存在しますが、これらには関係ないように見えます。

Yamaguchi commented 6 years ago

ちなみに、versionメッセージ送信する時のrelayフラグはfalseにしてます。

azuchi commented 6 years ago

primaryのピアのみでgetheadersを送信しているのは、同じブロックを複数回受信しても意味がないからという理解。

はい合ってます。ただ安全性を考えると今後、複数のピアからダウンロードしてチェーンの正しさを検証する必要があると考えてます。

ピアが複数の場合は、ブロックヘッダーの情報はprimaryから取得/更新し、filter_load/addしたtxの情報はprimaryでないピアから取得するという動作仕様でよいか?(ピア数=1の場合の問題は残る)

実装としては、primaryかどうかの判定はせず、inv〜merkleblock,txなどのメッセージを受信したピアで更新するようになっていれば良いかと思います。

Yamaguchi commented 6 years ago

rebase と relayフラグのデフォルト値変更を行いました。

Yamaguchi commented 6 years ago

TODO :