From: Isidor Zeuner <cryptocurrencies@quidecco•de>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
Date: Thu, 22 Jan 2015 01:44:16 +0100 (CET) [thread overview]
Message-ID: <20150122004416.93EFDE27748@quidecco.de> (raw)
In-Reply-To: <CANEZrP1Wh_98+47PmmHwSTDoSASw96R+Xnh5qWzROdmxPwO0Gw@mail.gmail.com>
Hi there,
some thoughts in-line:
> >
> > Finally, distributors of consumer wallets can use this research in
> > order to distribute their wallet with policies which may be less prone
> > to Tor-specific attacks. Or leave this out altogether if their
> > audience has different expectations for connecting to Bitcoin.
> >
>
> Sure. I guess there will be wallets for all kinds of people in future,
> sharing a common core that they can customise (this is certainly the vision
> and general direction for bitcoinj, and it's working out OK).
>
> To clarify, my comments above were for mainstream granny-focused wallets.
> Wallets designed for crypto geeks can and should expose all the knobs to
> let people run wild.
>
I hear that. But I don't see why mainstream wallets and wallets
designed for crypto research should not share a common core. Nor do I
understand why having a common core for different types of wallets
should be reserved for BitcoinJ.
When Bitcoin was pretty new, having a less customizable core did
probably have more of a merit in order to achieve network stability
through monoculture. But as of today, Bitcoin has proven itself as
being capable of allowing a variety of client application to run on
the network, so why should the reference implementation not reflect
this kind of diversity? The policy the mainstream distribution imposes
upon the core can still be rather restrictive.
> One possible direction to go is to use Tor for writing to the network and
> use general link encryption and better Bloom filtering for reading it. Thus
> new transactions would pop out of Tor exits, but there isn't much they can
> do that's malicious there except mutate them or block them entirely. If you
> insert the same transaction into the P2P network via say 10 randomly chosen
> exits, the worst a malicious mutator can do is race the real transaction
> and that's no different to a malicious P2P node. Even in a world where an
> attacker has DoS-banned a lot of nodes and now controls your TX submission
> path entirely, it's hard to see how it helps them.
>
It might deserve some research in order to determine how Tor's
privacy guarantees might be impacted if we allow attackers to mess
around with exit node choices in a rather predictable and low-cost
manner. Unfortunately, I can't think of another (non-Bitcoin)
application which puts Tor to a similar test.
> The nice thing about the above approach is that it solves the latency
> problems. Startup speed is really an issue for reading from the network:
> just syncing the block chain is already enough of a speed hit without
> adding consensus sync as well. But if you're syncing the block chain via
> the clearnet you can connect to Tor in parallel so that by the time the
> user has scanned a QR code, verified the details on the screen and then
> pressed the Pay button, you have a warm connection and can upload the TX
> through that. It reduces the level of startup time optimisation needed,
> although Tor consensus download is still too slow even to race a QR code
> scan at the moment. I think tuning the consensus caching process and
> switching to a fresh one on the fly might be the way to go.
>
I do agree that hybrid clearnet/Tor approaches come with interesting
performance properties.
> When BIP70 is in use, you wouldn't write the tx to the network yourself but
> you could download the PaymentRequest and upload the Payment message via an
> SSLd Tor connection to the merchant. Then malicious exits can only DoS you
> but not do anything else so there's no need for multiple exit paths
> simultaneously.
>
BIP70 is interesting, indeed, although I still fail to understand why
(according to the specs I saw) the PaymentRequest message is signed,
but not the Payment message.
But in context of the discussed protocol issues, I think it just moves
the issue from the payer to the payee, so it may or may not partially
relieve network-related issues, depending on the usage scenario.
Best regards,
Isidor
next prev parent reply other threads:[~2015-01-22 1:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-26 7:47 Jean-Paul Kogelman
2014-11-26 13:51 ` Jeff Garzik
2014-11-26 17:13 ` odinn
2014-11-27 2:09 ` Isidor Zeuner
2014-11-27 2:22 ` Gregory Maxwell
2014-11-27 11:06 ` Mike Hearn
2014-11-27 11:27 ` Wladimir
2014-12-08 16:15 ` Isidor Zeuner
2014-12-08 16:59 ` Mike Hearn
2015-01-22 0:44 ` Isidor Zeuner [this message]
2015-01-22 13:20 ` Mike Hearn
2014-12-15 13:25 ` Isidor Zeuner
2014-12-01 10:42 ` Isidor Zeuner
2014-11-27 17:44 Mistr Bigs
2014-11-27 20:30 ` Gregory Maxwell
2014-11-28 0:45 Mistr Bigs
2014-11-28 5:30 ` Gregory Maxwell
2014-12-11 11:51 ` Isidor Zeuner
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=20150122004416.93EFDE27748@quidecco.de \
--to=cryptocurrencies@quidecco$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/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