📅 Original date posted:2015-07-24
📝 Original message:On 07/23/2015 08:42 PM, Slurms MacKenzie via bitcoin-dev wrote:
>> From: "Eric Voskuil via bitcoin-dev"
>>
>> 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.
>
> 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.
Yes, quite true. And without the ability to search using filters there
is no private restore from backup short of downloading the full chain,
rendering the idea rather pointless.
This is why privacy remains a significant issue. Privacy is an essential
aspect of fungibility. This is a central problem for Bitcoin. The
correlation of addresses within transactions is of course problematic.
Possibly zero knowledge proof will at some point come to the rescue. But
the correlation of addresses via search works against the benefits of
address non-reuse, and the correlation of addresses to IP addresses
works against the use of private addresses.
Solving the latter two problems can go a long way to reducing the impact
of the former. But currently the only solution is to run a full chain
wallet. This is not a viable solution for many scenarios, and getting
less so.
This is not a problem that can be ignored, nor is it unique to Electrum.
The Bloom filter approach was problematic, but that doesn't preclude the
existence of valid solutions.
> 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.
Well because of presumed relationship in time these are not actually
separated requests. Which is why even the (performance-unrealistic)
option of a distinct Tor route for each independent address request is
*still* problematic.
> 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.
Introducing truly-random timing variations into the mixnet solutions can
mitigate timing attacks, but yes, this just makes the already
intolerable performance problem much worse.
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/d0b298ac/attachment.sig>;
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 15:42:47
in reply to nevent1q…f8ed
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:42:47Event JSON
{
"id": "d86fb77d5d8efd0ad356316750a10d083a1fd0f72f3aa15c7b5e25e43c59b141",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686152567,
"kind": 1,
"tags": [
[
"e",
"118b9de54e189b18402c92d943ea538ff30d5f541b4aeaba9bb62ae15123b652",
"",
"root"
],
[
"e",
"71a1ccb8bd9a86103499e9317d1f0aecaf29155fd4c1471a83611041c794967a",
"",
"reply"
],
[
"p",
"d1e5e343064328be063c36deb0dacb660b8589dcbca90112f9c449503b63ebba"
]
],
"content": "📅 Original date posted:2015-07-24\n📝 Original message:On 07/23/2015 08:42 PM, Slurms MacKenzie via bitcoin-dev wrote:\n\u003e\u003e From: \"Eric Voskuil via bitcoin-dev\"\n\u003e\u003e\n\u003e\u003e From our perspective, another important objective of query privacy is\n\u003e\u003e allowing the caller make the trade-off between the relative levels of\n\u003e\u003e privacy and performance - from absolute to non-existent. In some\n\u003e\u003e cases privacy is neither required nor desired.\n\u003e\u003e\n\u003e\u003e Prefix filtering accomplishes the client-tuning objective. It also\n\u003e\u003e does not suffer server collusion attacks nor is it dependent on\n\u003e\u003e computational bounds. The primary trade-off becomes result set\n\u003e\u003e (download) size against privacy.\n\u003e\n\u003e Keep in mind this is the similar premise as claimed to be offered by\n\u003e BIP37 bloom filters, but faulty assumptions and implementation\n\u003e failure in BitcoinJ have meant that bloom filters uniquely identify\n\u003e the wallet and offer no privacy for the user no matter what the\n\u003e settings are.\n\nYes, quite true. And without the ability to search using filters there\nis no private restore from backup short of downloading the full chain,\nrendering the idea rather pointless.\n\nThis is why privacy remains a significant issue. Privacy is an essential\naspect of fungibility. This is a central problem for Bitcoin. The\ncorrelation of addresses within transactions is of course problematic.\nPossibly zero knowledge proof will at some point come to the rescue. But\nthe correlation of addresses via search works against the benefits of\naddress non-reuse, and the correlation of addresses to IP addresses\nworks against the use of private addresses.\n\nSolving the latter two problems can go a long way to reducing the impact\nof the former. But currently the only solution is to run a full chain\nwallet. This is not a viable solution for many scenarios, and getting\nless so.\n\nThis is not a problem that can be ignored, nor is it unique to Electrum.\nThe Bloom filter approach was problematic, but that doesn't preclude the\nexistence of valid solutions.\n\n\u003e If you imagine a system where there is somehow complete\n\u003e separation and anonymization between all requests and subscriptions,\n\u003e the timing still leaks the association between the addresses to the\n\u003e listeners.\n\nWell because of presumed relationship in time these are not actually\nseparated requests. Which is why even the (performance-unrealistic)\noption of a distinct Tor route for each independent address request is\n*still* problematic.\n\n\u003e The obvious solution to that is to use a very high latency\n\u003e mix network, but I somehow doubt that there's any desire for a wallet\n\u003e with SPV security that takes a week to return results.\n\nIntroducing truly-random timing variations into the mixnet solutions can\nmitigate timing attacks, but yes, this just makes the already\nintolerable performance problem much worse.\n\ne\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/d0b298ac/attachment.sig\u003e",
"sig": "e0242fd0abf8c87f9e49598b1bdf1ff47005ca0da5535c06a3242364371321bcadb8ec9e5df87047021d35b41a9f0e9b0243f02851282f7f9197cf6e4a04b176"
}