đź“… Original date posted:2018-04-15
đź“ť Original message: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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Andreas Schildbach [ARCHIVE] /
npub1xg…adsv7
2023-06-07 18:11:39
in reply to nevent1q…ylnk
Author Public Key
npub1xg2m84malu0cfm4444r0kysx4rgk27e75aj6sz6538kw8fcz627qeadsv7Published at
2023-06-07 18:11:39Event JSON
{
"id": "9dd24f2fbe16ca2590c10843ae6efd22f46e53ee52ec98cad5a1cdba6df9c117",
"pubkey": "3215b3d77dff1f84eeb5ad46fb1206a8d1657b3ea765a80b5489ece3a702d2bc",
"created_at": 1686161499,
"kind": 1,
"tags": [
[
"e",
"431675dd201d4efe08b3fd18d9592208d5d38c3979f48e659b5f87d005a1a5a5",
"",
"root"
],
[
"e",
"681c929338c74075fb9a94b9c5fca18dd15444283e3a4405c297f258a4a6df57",
"",
"reply"
],
[
"p",
"9e2723f47c6c16d3093735bd6acdc8b0dd1b91c78216f7001bdd2f7562b69ed1"
]
],
"content": "📅 Original date posted:2018-04-15\n📝 Original message:Yes, I guess the quicker filter exhaustion must be the reason why\nbitcoinj doesn't make use of outpoints in filters for standard\ntransactions. I'll look into if I can change that.\n\n\nOn 04/14/2018 06:14 PM, Christian Decker via bitcoin-dev wrote:\n\u003e Note that this would compound the privacy leak that Jonas Nick used to\n\u003e identify address clusters via the bloom filters in one of his\n\u003e publications. By reducing the false positives when matching you can get\n\u003e very detailed clusters. Then again we know that bloom filters aren't\n\u003e good for privacy anyway, so this might be a non-issue.\n\u003e \n\u003e On Sat, Apr 14, 2018, 00:17 Jim Posen via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e Why not add the outpoints owned by the wallet to the filter and\n\u003e watch for those instead of elements in the input script or witness data?\n\u003e \n\u003e On Fri, Apr 13, 2018 at 12:12 PM, Jonas Schnelli via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e Hi Andreas\n\u003e \n\u003e Thanks for bringing this up and this seems indeed to be suboptimal.\n\u003e \n\u003e \u003e I wonder if Bitcoin Core would be willing to extend the BIP37 matching\n\u003e \u003e rules such that data elements in the witness are also matched against?\n\u003e \n\u003e Bitcoin Core is not an identity that can be „willing to extend“\n\u003e (or reject) a feature.\n\u003e Someone needs to come up with a proposal (pull request).\n\u003e \n\u003e Maybe an extension for BIP37 would make sense (*meh*).\n\u003e Just inserting the witness data into the bloom filter seems to\n\u003e be an easy solution (CBloomFilter::IsRelevantAndUpdate())\n\u003e \n\u003e /jonas\n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e",
"sig": "a637c451deb36da69119f55517020afc9e4b20ac262e167fe9fa9606dce9954ba1c7de99de06f9bd056b9c05a547ae67a5247e93012df16eed4f4959c518f437"
}