Re: [bitcoin-dev] BloomFilter issue with segwit addresses
As I understand it, the plan is to deprecated and remove BIP37 entirely once BIP158 is implemented and deployed. In the meantime, Bitcoin Knots supports the MSG_FILTERED_WITNESS_BLOCK extension to download witness data. (Note that light clients currently have no way to verify the witness data is correct.) As far as matching goes, why not look for the specific COutPoints? That should work already with standard BIP37. Luke On Friday 13 April 2018 3:32:15 PM Andreas Schildbach via bitcoin-dev wrote: > Anton, a developer on the bitcoinj maiing list, recently made me aware > [1] of a compatibility issue between segwit and BIP37 (Bloom Filtering). > > The issue affects only P2WPKH and the special case of transactions > without change outputs (such as when emptying a wallet). In this case, > neither inputs not outputs contain any data elements that would cause a > match for the filter. The public key, which would match, goes to the > witness but not to the input. > > My suggestion was to include an OP_RETURN output with a matching public > key in such transactions. Anton confirmed that this workaround is indeed > working. But of course it nullifies some of the segwit's size improvements. > > I wonder if Bitcoin Core would be willing to extend the BIP37 matching > rules such that data elements in the witness are also matched against? > > > [1] https://groups.google.com/d/msg/bitcoinj/SJpLgjowc1I/V7u2BavvAwAJ > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BloomFilter issue with segwit addresses
Why not add the outpoints owned by the wallet to the filter and watch for those instead of elements in the input script or witness data? On Fri, Apr 13, 2018 at 12:12 PM, Jonas Schnelli via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Andreas > > Thanks for bringing this up and this seems indeed to be suboptimal. > > > I wonder if Bitcoin Core would be willing to extend the BIP37 matching > > rules such that data elements in the witness are also matched against? > > Bitcoin Core is not an identity that can be „willing to extend“ (or > reject) a feature. > Someone needs to come up with a proposal (pull request). > > Maybe an extension for BIP37 would make sense (*meh*). > Just inserting the witness data into the bloom filter seems to be an easy > solution (CBloomFilter::IsRelevantAndUpdate()) > > /jonas > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BloomFilter issue with segwit addresses
Hi Andreas Thanks for bringing this up and this seems indeed to be suboptimal. > I wonder if Bitcoin Core would be willing to extend the BIP37 matching > rules such that data elements in the witness are also matched against? Bitcoin Core is not an identity that can be „willing to extend“ (or reject) a feature. Someone needs to come up with a proposal (pull request). Maybe an extension for BIP37 would make sense (*meh*). Just inserting the witness data into the bloom filter seems to be an easy solution (CBloomFilter::IsRelevantAndUpdate()) /jonas signature.asc Description: Message signed with OpenPGP ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] BloomFilter issue with segwit addresses
Anton, a developer on the bitcoinj maiing list, recently made me aware [1] of a compatibility issue between segwit and BIP37 (Bloom Filtering). The issue affects only P2WPKH and the special case of transactions without change outputs (such as when emptying a wallet). In this case, neither inputs not outputs contain any data elements that would cause a match for the filter. The public key, which would match, goes to the witness but not to the input. My suggestion was to include an OP_RETURN output with a matching public key in such transactions. Anton confirmed that this workaround is indeed working. But of course it nullifies some of the segwit's size improvements. I wonder if Bitcoin Core would be willing to extend the BIP37 matching rules such that data elements in the witness are also matched against? [1] https://groups.google.com/d/msg/bitcoinj/SJpLgjowc1I/V7u2BavvAwAJ ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
