From: "Slurms MacKenzie" <slurms@gmx•us>
To: "Eric Voskuil" <eric@voskuil•org>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Making Electrum more anonymous
Date: Fri, 24 Jul 2015 11:38:44 +0200 [thread overview]
Message-ID: <trinity-8808ac13-3a67-4337-a9c8-fcb361ea071e-1437730724154@3capp-mailcom-bs01> (raw)
In-Reply-To: <55B1C2A2.6020704@voskuil.org>
> Sent: Friday, July 24, 2015 at 6:44 AM
> From: "Eric Voskuil" <eric@voskuil•org>
> To: "Slurms MacKenzie" <slurms@gmx•us>, bitcoin-dev@lists•linuxfoundation.org
> Subject: Re: [bitcoin-dev] Making Electrum more anonymous
>
> This is why privacy remains a significant issue. Privacy is an essential
> aspect of fungibility. This is a central problem for Bitcoin.
Somewhat under discussed too, really. Peoples money doesn't fly out the window when their privacy is ripped out from under them, as such discussing it seems a little meaningless. As some of the most popular wallets don't even use change addresses, for the comfort of the developers and at the cost of the user.
> 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.
Which makes the general clambering for demise of the full node wallet all the more baffling.
> 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.
Yep, any leak is a useful leak. Even if you only expose one single address request to me, I now have an idea of what timezone you are in and can eliminate it from other implausible ones. Onion routing is not a solution in my mind, you're just asking for people to sybil attack Electrum clients to capture as much timing data as possible. There's no defending against that.
> 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.
Realistically this is all too broken to be building wallets on top of.
SPV clients are neither secure nor private, we should feel guilty for ever promoting them.
next prev parent reply other threads:[~2015-07-24 9:38 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 15:51 Thomas Voegtlin
2015-07-22 16:04 ` Natanael
2015-07-22 16:30 ` Eric Voskuil
2015-07-22 22:20 ` Eric Voskuil
2015-07-22 23:07 ` Joseph Gleason ⑈
2015-07-22 16:41 ` Joseph Gleason ⑈
2015-07-22 21:18 ` Mike Hearn
2015-07-22 23:11 ` gb
2015-07-23 0:07 ` Eric Voskuil
[not found] ` <114b2a76-ebc7-461a-b4bc-10873574d6c4@HUB2.rwth-ad.de>
2015-07-23 12:23 ` Stefan Richter
2015-07-24 2:26 ` Eric Voskuil
2015-07-24 3:42 ` Slurms MacKenzie
2015-07-24 4:44 ` Eric Voskuil
2015-07-24 9:38 ` Slurms MacKenzie [this message]
2015-07-24 11:12 ` s7r
2015-07-24 21:20 ` Slurms MacKenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=trinity-8808ac13-3a67-4337-a9c8-fcb361ea071e-1437730724154@3capp-mailcom-bs01 \
--to=slurms@gmx$(echo .)us \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@voskuil$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox