* [bitcoin-dev] BloomFilter issue with segwit addresses
@ 2018-04-13 15:32 Andreas Schildbach
2018-04-13 19:12 ` Jonas Schnelli
2018-04-13 22:52 ` Luke Dashjr
0 siblings, 2 replies; 7+ messages in thread
From: Andreas Schildbach @ 2018-04-13 15:32 UTC (permalink / raw)
To: bitcoin-dev
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BloomFilter issue with segwit addresses
2018-04-13 15:32 [bitcoin-dev] BloomFilter issue with segwit addresses Andreas Schildbach
@ 2018-04-13 19:12 ` Jonas Schnelli
2018-04-13 22:15 ` Jim Posen
2018-04-13 22:52 ` Luke Dashjr
1 sibling, 1 reply; 7+ messages in thread
From: Jonas Schnelli @ 2018-04-13 19:12 UTC (permalink / raw)
To: Andreas Schildbach, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 575 bytes --]
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
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BloomFilter issue with segwit addresses
2018-04-13 19:12 ` Jonas Schnelli
@ 2018-04-13 22:15 ` Jim Posen
2018-04-14 16:14 ` Christian Decker
0 siblings, 1 reply; 7+ messages in thread
From: Jim Posen @ 2018-04-13 22:15 UTC (permalink / raw)
To: Andreas Schildbach; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]
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
>
>
[-- Attachment #2: Type: text/html, Size: 1618 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BloomFilter issue with segwit addresses
2018-04-13 22:15 ` Jim Posen
@ 2018-04-14 16:14 ` Christian Decker
2018-04-14 19:46 ` Jim Posen
2018-04-15 18:37 ` Andreas Schildbach
0 siblings, 2 replies; 7+ messages in thread
From: Christian Decker @ 2018-04-14 16:14 UTC (permalink / raw)
To: Jim Posen, Bitcoin development mailing list
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
Note that this would compound the privacy leak that Jonas Nick used to
identify address clusters via the bloom filters in one of his publications.
By reducing the false positives when matching you can get very detailed
clusters. Then again we know that bloom filters aren't good for privacy
anyway, so this might be a non-issue.
On Sat, Apr 14, 2018, 00:17 Jim Posen via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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
>
[-- Attachment #2: Type: text/html, Size: 2748 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BloomFilter issue with segwit addresses
2018-04-14 16:14 ` Christian Decker
@ 2018-04-14 19:46 ` Jim Posen
2018-04-15 18:37 ` Andreas Schildbach
1 sibling, 0 replies; 7+ messages in thread
From: Jim Posen @ 2018-04-14 19:46 UTC (permalink / raw)
To: Christian Decker; +Cc: Bitcoin development mailing list
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]
To Christian's point about privacy, I'll take this opportunity to
shamelessly review beg on https://github.com/bitcoin/bitcoin/pull/12254,
the PR for BIP 158 implementation (but not 157).
On Sat, Apr 14, 2018 at 9:14 AM, Christian Decker <
decker.christian@gmail•com> wrote:
> Note that this would compound the privacy leak that Jonas Nick used to
> identify address clusters via the bloom filters in one of his publications.
> By reducing the false positives when matching you can get very detailed
> clusters. Then again we know that bloom filters aren't good for privacy
> anyway, so this might be a non-issue.
>
> On Sat, Apr 14, 2018, 00:17 Jim Posen via bitcoin-dev <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
>
>> 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
>>
>
[-- Attachment #2: Type: text/html, Size: 3513 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BloomFilter issue with segwit addresses
2018-04-14 16:14 ` Christian Decker
2018-04-14 19:46 ` Jim Posen
@ 2018-04-15 18:37 ` Andreas Schildbach
1 sibling, 0 replies; 7+ messages in thread
From: Andreas Schildbach @ 2018-04-15 18:37 UTC (permalink / raw)
To: bitcoin-dev
Yes, I guess the quicker filter exhaustion must be the reason why
bitcoinj doesn't make use of outpoints in filters for standard
transactions. I'll look into if I can change that.
On 04/14/2018 06:14 PM, Christian Decker via bitcoin-dev wrote:
> Note that this would compound the privacy leak that Jonas Nick used to
> identify address clusters via the bloom filters in one of his
> publications. By reducing the false positives when matching you can get
> very detailed clusters. Then again we know that bloom filters aren't
> good for privacy anyway, so this might be a non-issue.
>
> On Sat, Apr 14, 2018, 00:17 Jim Posen via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org
> <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
>
> 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
> <mailto: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
> <mailto:bitcoin-dev@lists•linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> <mailto: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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoin-dev] BloomFilter issue with segwit addresses
2018-04-13 15:32 [bitcoin-dev] BloomFilter issue with segwit addresses Andreas Schildbach
2018-04-13 19:12 ` Jonas Schnelli
@ 2018-04-13 22:52 ` Luke Dashjr
1 sibling, 0 replies; 7+ messages in thread
From: Luke Dashjr @ 2018-04-13 22:52 UTC (permalink / raw)
To: bitcoin-dev, Andreas Schildbach
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-04-15 18:37 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-13 15:32 [bitcoin-dev] BloomFilter issue with segwit addresses Andreas Schildbach
2018-04-13 19:12 ` Jonas Schnelli
2018-04-13 22:15 ` Jim Posen
2018-04-14 16:14 ` Christian Decker
2018-04-14 19:46 ` Jim Posen
2018-04-15 18:37 ` Andreas Schildbach
2018-04-13 22:52 ` Luke Dashjr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox