Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-12-08 Thread Isidor Zeuner
 
  [As an aside I agree that there are lots of things to improve here,
  but the fact that users can in theory be forced off of tor via DOS
  attacks is not immediately concerning to me because its a conscious
  choice users would make to abandon their privacy


 Bitcoin already has a large population of users who have little or no
 technical skill, it wouldn't surprise me at all if it was found to be the
 clear majority by now. Assuming success and growth in future, very few
 users will make any decisions at all about their privacy, they will just
 accept the defaults. In such a world no consumer wallet is going to
 directly expose Tor to end users - if used at all it'll just be used behind
 the scenes. So automated fallback or control over exits would be a concern
 for such wallets.


In order to get more synergy between Bitcoin users of varying skill
levels, my suggestion would be a cleaner separation between technical
mechanisms and policies (possibly suitable for users without technical
skills).

Core development would mean providing suitable mechanisms by which it
is possible to run Bitcoin on different constraints. This may include
ways to handle attacks specific to the Tor/Bitcoin combination.

People who like to research what is possible with the protocol can
then experiment on how these mechanisms can be used in order to
mitigate these attacks.

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.

The tricky part is probably to figure out what is the greatest common
denominator of what keeps Bitcoin stable and running while still
leaving room for customized policies. But I think that separating
concerns like this is better than letting a debate about how to
mitigate certain Tor-related attacks evolve towards a debate about Tor
or not Tor.

 My gut feeling about this stuff has changed over time. I don't think it'd
 be a great idea to tie Bitcoin to Tor too deeply, convenient though its
 infrastructure is. Most apps don't need a whole lot of onion routing - a
 small amount built in to the p2p layer would be sufficient. Tor is huge,
 complicated and could be a liability in future.


I think it would be very interesting to explore alternatives for
Tor. But at this point, completely abandoning Tor would mean that
users either have to agree to have their transactions correlated to
their IP address, or to trust their transactions to a third party
where they are not subject to the security guarantees Bitcoin's
logic can provide anymore. In my opinion, it's a rather huge
sacrifice.

What I find interesting, however, is that a lot of suggestions I see
with respect to attacks related to Tor/Bitcoin (including my own)
involve some kind of extra effort required for Tor users on Bitcoin in
order to protect themselves against these attacks. So, it may be
interesting to explore if it is viable to think of Tor's privacy
guarantees as coming for free. Going from there, if it cannot be
guaranteed to work completely for free, the question would be to what
extent the required extra effort should be a shared effort of the
network, and to what extent users requiring the improved privacy
should use their own resources in order to make it possible.

Best regards,

Isidor

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-12-08 Thread Mike Hearn

 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.

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.

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.

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.
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development