📅 Original date posted:2015-07-24
📝 Original message:Keep in mind this is the similar premise as claimed to be offered by BIP37 bloom filters, but faulty assumptions and implementation failure in BitcoinJ have meant that bloom filters uniquely identify the wallet and offer no privacy for the user no matter what the settings are. If you imagine a system where there is somehow complete separation and anonymization between all requests and subscriptions, the timing still leaks the association between the addresses to the listeners. The obvious solution to that is to use a very high latency mix network, but I somehow doubt that there's any desire for a wallet with SPV security that takes a week to return results.
> Sent: Friday, July 24, 2015 at 4:26 AM
> From: "Eric Voskuil via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org>
> To: "Stefan Richter" <richter at cs.rwth-aachen.de>, gb <kiwigb at yahoo.com>, "Thomas Voegtlin" <thomasv at electrum.org>
> Cc: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Making Electrum more anonymous
>
>
> From our perspective, another important objective of query privacy is
> allowing the caller make the trade-off between the relative levels of
> privacy and performance - from absolute to non-existent. In some cases
> privacy is neither required nor desired.
>
> Prefix filtering accomplishes the client-tuning objective. It also does
> not suffer server collusion attacks nor is it dependent on computational
> bounds. The primary trade-off becomes result set (download) size against
> privacy.
>
Slurms MacKenzie [ARCHIVE] /
npub168…hhm7q
2023-06-07 15:42:47
in reply to nevent1q…h94l
Author Public Key
npub168j7xscxgv5tup3uxm0tpkktvc9ctzwuhj5szyhec3y4qwmrawaq9hhm7qSeen on
wss://relay.nostr.bandPublished at
2023-06-07 15:42:47Event JSON
{
"id": "71a1ccb8bd9a86103499e9317d1f0aecaf29155fd4c1471a83611041c794967a",
"pubkey": "d1e5e343064328be063c36deb0dacb660b8589dcbca90112f9c449503b63ebba",
"created_at": 1686152567,
"kind": 1,
"tags": [
[
"e",
"118b9de54e189b18402c92d943ea538ff30d5f541b4aeaba9bb62ae15123b652",
"",
"root"
],
[
"e",
"575947c67e415c14bbf83926bd369daa479fbb07f168c1b0bca15b49bb204be3",
"",
"reply"
],
[
"p",
"82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e"
]
],
"content": "📅 Original date posted:2015-07-24\n📝 Original message:Keep in mind this is the similar premise as claimed to be offered by BIP37 bloom filters, but faulty assumptions and implementation failure in BitcoinJ have meant that bloom filters uniquely identify the wallet and offer no privacy for the user no matter what the settings are. If you imagine a system where there is somehow complete separation and anonymization between all requests and subscriptions, the timing still leaks the association between the addresses to the listeners. The obvious solution to that is to use a very high latency mix network, but I somehow doubt that there's any desire for a wallet with SPV security that takes a week to return results. \n\n\n\u003e Sent: Friday, July 24, 2015 at 4:26 AM\n\u003e From: \"Eric Voskuil via bitcoin-dev\" \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e To: \"Stefan Richter\" \u003crichter at cs.rwth-aachen.de\u003e, gb \u003ckiwigb at yahoo.com\u003e, \"Thomas Voegtlin\" \u003cthomasv at electrum.org\u003e\n\u003e Cc: bitcoin-dev at lists.linuxfoundation.org\n\u003e Subject: Re: [bitcoin-dev] Making Electrum more anonymous\n\u003e\n\u003e \n\u003e From our perspective, another important objective of query privacy is\n\u003e allowing the caller make the trade-off between the relative levels of\n\u003e privacy and performance - from absolute to non-existent. In some cases\n\u003e privacy is neither required nor desired.\n\u003e \n\u003e Prefix filtering accomplishes the client-tuning objective. It also does\n\u003e not suffer server collusion attacks nor is it dependent on computational\n\u003e bounds. The primary trade-off becomes result set (download) size against\n\u003e privacy.\n\u003e",
"sig": "8116e4914fa6244cadebc94da65048dc5ff2c1cb85315eaa9c60a5b11c151004b3f4f943238ac03564a482059c2cc002ae0ffbabe38d6bac8099ab51794ddd85"
}