Compact Client Side Filtering for Light Clients (Neutrino server-side support) #11863
Comments
|
Personally I think the protocol has a little ways to go in terms of being well-specified and KISS, but as for proof of concept: a) until things settle, use a testing service bit and not the final one, and b) I believe @jimpo was looking into doing it cleanly, so maybe follow up with him.
…On December 11, 2017 8:57:08 AM EST, Sjors Provoost ***@***.***> wrote:
@Roasbeef, @martelletto and @aakselrod implemented server-side support
for this protocol in the btcd client, and the lnd Lightning client is
able to use this.
Are there any prerequisites for implementing server-side support for
this protocol in Bitcoin Core, at least as a proof of concept?
* [draft
BIP](https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki)
* [video presentation](https://www.youtube.com/watch?v=7FWKc8lM4Ek)
about the neutrino protocol
* [btcd
implementation](btcsuite/btcd@master...Roasbeef:segwit-cbf)
* [mailinglist
discussion](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014474.html)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#11863
|
|
@jonasschnelli I believe the question was about server-side support (ie serving neutrino headers/filters), not client-side SPV support. |
|
@TheBlueMatt correct. The other way around should be a separate Github issue if anyone is interested, as it has completely different trade-offs. |
|
Note that in the |
|
Sorry for the confusion. |
|
Related: #12254 |
|
The replacement pull request of the linked PR (609) was merged and test vectors have been added to BIP 158. |
|
#14121 adds an index for these filters The step after that is probably implementing p2p messages that use this index if it's enabled. |
|
I don't think adding more code to Core is the best design we can have since this can be developed as an external service by fetching blocks from Core. The users that don't want to provide this service (for security or performance reasons) shouldn't be forced to have such code compiled-in. But maybe I'm missing something? |
|
@Kixunil I agree that an external service is a valid alternative design choice. However, I believe adding BIP 157 support directly into Core is the better design. The security of light clients using the protocol improves with the number of nodes on the network serving filters (at least until filters are committed into block headers if/when that happens). Adding support into Core gives all node operators an easy ability to support light clients with a single configuration flag without having to install/audit/trust a new project. Furthermore, keeping an index of block filters improves rescan speed for full node wallets (by 80+% by my measurements for a 1,000 key wallet). The code is designed to be minimally invasive by using the asynchronous CValidationInterface callbacks and does not modify consensus code or core data structures at all. If you have specific security or performance concerns, please comment on the PR. I also think you are underestimating how much work would be involved in creating an external service. Such a service would need to expose the full Bitcoin P2P network interface (or at least a lot of it), which is very non-trivial and arguably much riskier for the network as a whole than Core adding support for a few more requests. Reimplementing the network layer as a proxy node has been discussed before and I'd love to see someone do it, but I'm skeptical that it would reach the same level of stability or support that Core has any time soon. |
|
My two cents: I don't think this should be part of core (but nice rescan perf improvements). In my view it makes more sense as a thin shin in front of core. And if this had to be part of core I think it should be off by default anyway. I am not sure if the protocol has to be based on bitcoin p2p but if we assume it has to then something like https://github.com/basil00/PseudoNode or https://github.com/rust-bitcoin/rust-bitcoin may be a good starting point to handle bitcoin p2p messages? |
|
@jimpo Thanks for detailed answer! TBH, I'd love to see the wallet get removed from Core as well, but since that's almost certainly not going to happen anytime soon, I consider the argument about increased rescan speed convincing enough to implement block filters. Once they are implemented, it makes a lot of sense to expose them as well (ideally behind configuration flag). Installing/trusting other pieces of software is already a problem that people need to solve (e.g. for Btcpay server, HW wallets with ElectrumX/EPS...) Docker, scripts, or manual install (tons of tutorials) are popular methods when it comes to installing. If there's something missing, maybe making better tools would help the ecosystem overall. When it comes to audit, I wouldn't object to Core developers also auditing external service and provide their signatures, if they want to. I didn't want to suggest to use the Bitcoin P2P protocol, but some other protocol. Electrum uses the same approach and I don't see anything wrong with it. But again, I may be missing something. Finally, I'm wondering if it's possible to use block filters with pruned node. It seems possible to me (build filters during sync, keep filters, throw away old blocks). The advantage is obviously being able to rescan quickly and efficiently if it's needed later. Is this feature implemented/planned/a bad idea? |
Yes, but that needs to be implemented: #15867 |
|
I am going to close this issue, as it is unclear what is being discussed here exactly. |
|
#16442 implements this |
@Roasbeef, @martelletto and @aakselrod implemented server-side support for this protocol in the btcd client, and the lnd Lightning client is able to use this.
Are there any prerequisites for implementing server-side support for this protocol in Bitcoin Core, at least as a proof of concept?
The text was updated successfully, but these errors were encountered: