Discussion:
BloomFilter issue with segwit addresses
Add Reply
Andreas Schildbach via bitcoin-dev
2018-04-13 15:32:15 UTC
Reply
Permalink
Raw Message
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
Jonas Schnelli via bitcoin-dev
2018-04-13 19:12:47 UTC
Reply
Permalink
Raw Message
Hi Andreas

Thanks for bringing this up and this seems indeed to be suboptimal.
Post by Andreas Schildbach via bitcoin-dev
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

Loading...