📅 Original date posted:2015-02-20
📝 Original message:Hello Adam,
On Fri, 20 Feb 2015, Adam Back wrote:
> So I was wondering what about changing to committing a bloom filter of
> the addresses in the block. Its seems surprising no one thought of it
> that way before (as it seems obvious when you hear it) but that seems
> to address the privacy issues as the user can fetch the block bloom
> filters and then scan it in complete privacy. (Someone appeared on
> bitcoin wizards IRC a while back and made this observation.)
I have heard this idea of inverting the bloom filter before (possibly in
#bitcoin-wizards), and as I see it it would indeed improve the privacy.
Apart from privacy it would also lower the burden for nodes. A block scan
with bloom filter is effectively a cheap DoS on a node.
In addition to that it will also avoid the 'transaction withholding
attack' that is possible with the current bloom filtering, at least if the
filter is e.g. committed to in the block header.
The drawback would be overhead - the bloom filter per block will have a
significant size (to avoid false positives), and the client would have to
fetch entire blocks that have its transactions in it.
I don't think that is so bad in practice, after all the % of blocks that
will have transactions for a given wallet will generally be low, so the
block size is amortized in a way. Of course, if the block size would be
increased this would become worse.
Wladimir
Wladimir [ARCHIVE] /
npub1xq…ymc2p
2023-06-07 15:30:42
in reply to nevent1q…6kjv
Author Public Key
npub1xqshkqv2g7uea4xzqwvmgjcz7u8vfavw6aazs999v0azsv3w7u3qpymc2pSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:30:42Event JSON
{
"id": "43b97d672779f076f82e915736e7d73d604a990a2606abf77549d183929fe477",
"pubkey": "30217b018a47b99ed4c20399b44b02f70ec4f58ed77a2814a563fa28322ef722",
"created_at": 1686151842,
"kind": 1,
"tags": [
[
"e",
"d00e0f44d6037fd0ba68029864e2acf1e3fe5c4c51dbcdd7d112be31766cd3e9",
"",
"root"
],
[
"e",
"062e13ec403c45a337c4ed1a3eb9fb8fe766ec37fedaa4412d66df5fb9ac820f",
"",
"reply"
],
[
"p",
"ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a"
]
],
"content": "📅 Original date posted:2015-02-20\n📝 Original message:Hello Adam,\n\nOn Fri, 20 Feb 2015, Adam Back wrote:\n\n\u003e So I was wondering what about changing to committing a bloom filter of\n\u003e the addresses in the block. Its seems surprising no one thought of it\n\u003e that way before (as it seems obvious when you hear it) but that seems\n\u003e to address the privacy issues as the user can fetch the block bloom\n\u003e filters and then scan it in complete privacy. (Someone appeared on\n\u003e bitcoin wizards IRC a while back and made this observation.)\n\nI have heard this idea of inverting the bloom filter before (possibly in \n#bitcoin-wizards), and as I see it it would indeed improve the privacy. \nApart from privacy it would also lower the burden for nodes. A block scan \nwith bloom filter is effectively a cheap DoS on a node.\n\nIn addition to that it will also avoid the 'transaction withholding \nattack' that is possible with the current bloom filtering, at least if the \nfilter is e.g. committed to in the block header.\n\nThe drawback would be overhead - the bloom filter per block will have a \nsignificant size (to avoid false positives), and the client would have to \nfetch entire blocks that have its transactions in it.\n\nI don't think that is so bad in practice, after all the % of blocks that \nwill have transactions for a given wallet will generally be low, so the \nblock size is amortized in a way. Of course, if the block size would be \nincreased this would become worse.\n\nWladimir",
"sig": "51b5ddc54ed2387f940987df0a5e0f027aa9429a1eefb554be93b29500590807676754acda987995651eecb655f62d4a5bfced14168d115c63b1ed24959ed52f"
}