Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Added support for MSG_FILTERED_WITNESS_BLOCK messages. #10350
After much deliberation and a few attempts at other approaches to provide a workable near-term sync mechanism for thin clients that require witness data, I decided to just go with the simplest short-term path with the least amount of complications expecting BIP37 to be completely replaced eventually - hopefully in the not-very-distant future.
I believe the approach of filtering blocks on the client is a simpler and superior approach for most use cases than requiring the server to perform the filtering. I believe @Roasbeef has something written up for this that he's using for lnd. I would love to see that approach used in Bitcoin Core as well.
But given the good likelihood of nearterm SegWit activation on the Bitcoin mainnet, I believe this solution will suffice for all essential use cases of BIP37 for now - and I don't believe it's worth the effort to try to make more complex additions to BIP37 since it will eventually be entirely replaced.
Peers can request MSG_FILTERED_WITNESS_BLOCK and will receive a merkleblock structure with transactions serialized with witnesses. The merkle proof for the witnesses is not supplied. This means that the client cannot verify that the witness data is what's actually in the block. However, the attack vectors here given the actual intended use cases seem extremely slim for several reasons:
referenced this pull request
May 7, 2017
My entire stack currently relies on BIP37 for synching with a node, including a number of testing tools I use. The alternatives of either maintaining a custom server (one more thick dependency) or using RPC (excruciatingly and impractically slow and inefficient) aren't really options for me at this point. So until we do something like clientside block filtering I'm left with either using this patch or having to hack something up that's really ugly on my end.
I understand that there's a desire to not pollute the codebase with stuff that most people probably will not use - so I fully understand if other devs are reluctant to want to merge this. But I do not believe it is particularly intrusive - it doesn't really get in the way of anyone else and is easy to review and test for correctness. And it would save at least some people a nontrivial amount of additional effort in having to maintain separate branches and patches.
I'm eager to contribute to the effort of finding a good long-term solution to the thin client sync issue and helping to implement it. But right now I need to make some important software releases, and the more I need to worry about my own software's short-term compatibility issues the less I can focus on the bigger picture.
Anyhow, I appreciate the consideration.