* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
@ 2014-11-27 17:44 Mistr Bigs
2014-11-27 20:30 ` Gregory Maxwell
0 siblings, 1 reply; 18+ messages in thread
From: Mistr Bigs @ 2014-11-27 17:44 UTC (permalink / raw)
To: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]
I might be mistaken, but it seems to me this paper discusses unintended
ways of obtaining the IP addresses of clients involved in transactions on
the core Bitcoin network.
Tor was mentioned only insofar as it might be one's first thought of how to
mitigate this risk, yet Bitcoin over Tor has its own problems that prevent
this from being effective.
But the primary "issues" mentioned in the paper are regarding a Bitcoin
node in default operation, no?
"In their new study, researchers at the Laboratory of Algorithmics,
Cryptology and Security of the University of Luxembourg have shown that
Bitcoin does not protect user's IP address and that it can be linked to the
user's transactions in real-time."
"The basic idea behind these findings is that Bitcoin entry nodes, to which
the user's computer connects in order to make a transaction, form a unique
identifier for the duration of user's session. This unique pattern can be
linked to a user's IP address. Moreover, transactions made during one
session, even those made via unrelated pseudonyms, can be linked together.
With this method, hackers can reveal up to 60 percent of the IP addresses
behind the transactions made over the Bitcoin network."
"'This Bitcoin network analysis combined with previous research on
transaction flows shows that the level of anonymity in the Bitcoin network
is quite low,' explains Dr. Alex Biryukov."
M
[-- Attachment #2: Type: text/html, Size: 1545 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
2014-11-27 17:44 [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper Mistr Bigs
@ 2014-11-27 20:30 ` Gregory Maxwell
0 siblings, 0 replies; 18+ messages in thread
From: Gregory Maxwell @ 2014-11-27 20:30 UTC (permalink / raw)
To: Mistr Bigs; +Cc: Bitcoin Development
On Thu, Nov 27, 2014 at 5:44 PM, Mistr Bigs <misterbg6@gmail•com> wrote:
> I might be mistaken, but it seems to me this paper discusses unintended ways
> of obtaining the IP addresses of clients involved in transactions on the
> core Bitcoin network.
You're mistaken. :)
If a node is used exclusively via tor it effectively doesn't have a IP address.
(short of bugs of a class that aren't discussed here)
The paper is about fingerprinting approaches that probabilistically
connect transactions to hosts that you can already identify their IPs.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
2015-01-22 0:44 ` Isidor Zeuner
@ 2015-01-22 13:20 ` Mike Hearn
0 siblings, 0 replies; 18+ messages in thread
From: Mike Hearn @ 2015-01-22 13:20 UTC (permalink / raw)
To: Isidor Zeuner; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
>
> I hear that. But I don't see why mainstream wallets and wallets
> designed for crypto research should not share a common core.
>
I think there was some misunderstanding. I was saying they *could and
should* share common cores, so we are in agreement without realising it :)
I also didn't mean to imply there was anything special about bitcoinj, just
that it's an example of a wallet engine that's already in use.
> 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.
>
Because it's intended to be submitted via HTTPS. But what would you sign
the message with? Some arbitrary key bound to the transaction?
[-- Attachment #2: Type: text/html, Size: 1161 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
2014-12-08 16:15 ` Isidor Zeuner
2014-12-08 16:59 ` Mike Hearn
@ 2015-01-22 0:44 ` Isidor Zeuner
2015-01-22 13:20 ` Mike Hearn
1 sibling, 1 reply; 18+ messages in thread
From: Isidor Zeuner @ 2015-01-22 0:44 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Development
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
2014-11-27 2:22 ` Gregory Maxwell
` (2 preceding siblings ...)
2014-12-08 16:15 ` Isidor Zeuner
@ 2014-12-15 13:25 ` Isidor Zeuner
3 siblings, 0 replies; 18+ messages in thread
From: Isidor Zeuner @ 2014-12-15 13:25 UTC (permalink / raw)
To: Wladimir; +Cc: Bitcoin Development
[...]
> > I'm confused by this, I run quite a few nodes exclusively on tor and
> > chart their connectivity and have seen no such connection dropping
> > behaviour.
>
> In my experience the problem has always been getting bootstrapped.
> Most nodes hardly give any hidden service nodes in their getaddr.
> (this has been improved in master by including a set of hidden service
> seed nodes)
> But this assumes -onlynet=tor. Tor with exit nodes should be less
> problematic, unless someone managed to DoSban all the exit nodes as
> described in the paper (but I've never seen such an attack myself).
>
When refering to "getting bootstrapped", do you only mean collecting
node addresses, or also syncing blocks?
If you're saying the drops in connection counts are likely to be
not caused by a DoSban attack on the exit nodes, what could be other
reasons to look into?
> > Can you tell me more about how you measured this?
> >
> > [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 (and the behaviour of
> > the system here is known and intentional). There are other mechanisms
> > available for people to relay their transactions than connecting
> > directly to the bitcoin network; so their choice isn't just abandon
> > privacy or don't use bitcoin at all.]
>
> Right, there's something to be said for splitting your own transaction
> submission from normal P2P networking and transaction relay.
> (esp for non-SPV wallets which don't inherently leak any information
> about their addresses)
>
> There was a pull request about this for Bitcoin Core one, maybe I
> closed it unfairly https://github.com/bitcoin/bitcoin/issues/4564 .
>
Great! I find it very interesting to research options for splitting
communication between Tor and non-Tor as long as the introduced
information leakage between both connection methods can be proved to
be nonexistent or negligible.
In the case of Bitcoin, this makes me wonder about an attack that
could look approximately like this:
* Node A connects to Bitcoin using Tor (for submitting transactions)
and IPv4 (for all other communication).
* Node B strives for direct IPv4 connections with node A
* Node B uses the direct IPv4 connections in order to supply Node A
with additional peer addresses not supplied to any other nodes
* Node B observes these additional peer addresses
For transactions submitted to the additional peer addresses supplied
by node B, how to prevent that the probability of these originating
from node A is higher than for originating from other nodes?
For handling block propagation using non-Tor connections, it's
probably harder to create information leaks, as the logic for handling
disagreement about blocks is pretty well-researched, meaning that
it's less important where the blocks come from.
Best regards,
Isidor
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
2014-11-28 0:45 Mistr Bigs
2014-11-28 5:30 ` Gregory Maxwell
@ 2014-12-11 11:51 ` Isidor Zeuner
1 sibling, 0 replies; 18+ messages in thread
From: Isidor Zeuner @ 2014-12-11 11:51 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
[...]
> And, on the flip side if the host is persistently behind tor, even
> with some watermarkable behaviour, their privacy is protected. So
> making sure that hosts can continually use tor (or similar systems)
> should be the higher priority. (And, of course, not reimplementing
> tor leverages the millions of dollars of investment and dozens of
> subject matter experts working on that system).
>
Reimplementing Tor would not only mean to lose all the investment that
ran into Tor, but also to lose a large user base. We can see this with
TorCoin. Still, the fact that Bitcoin is a use case for Tor which
measurably shows some limits where it is not fully clear if Tor or
Bitcoin is to be blamed does not only mean that both projects may
have to evolve in order to properly solve the issue, but also that the
means of interfacing between both projects may have to be
extended. Ideally, in a way which does not require to run a separate
Tor and/or Bitcoin network in order to work, but which will be generic
enough to satisfy both sides' need to still work in a standalone
manner.
But I do see huge merit in exploring better ways of synergy between
the projects. For example, Tor's hardcoded circuit length may be
considered as a hack which was only necessary due to the lack of a
suitable resource compensation mechanism. Which is something that is
available with Bitcoin.
Best regards,
Isidor
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
2014-12-08 16:15 ` Isidor Zeuner
@ 2014-12-08 16:59 ` Mike Hearn
2015-01-22 0:44 ` Isidor Zeuner
1 sibling, 0 replies; 18+ messages in thread
From: Mike Hearn @ 2014-12-08 16:59 UTC (permalink / raw)
To: Isidor Zeuner; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 2396 bytes --]
>
> 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.
[-- Attachment #2: Type: text/html, Size: 2791 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
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
2014-12-15 13:25 ` Isidor Zeuner
3 siblings, 2 replies; 18+ messages in thread
From: Isidor Zeuner @ 2014-12-08 16:15 UTC (permalink / raw)
To: Mike Hearn; +Cc: Bitcoin Development
> >
> > [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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
2014-11-27 2:09 ` Isidor Zeuner
2014-11-27 2:22 ` Gregory Maxwell
@ 2014-12-01 10:42 ` Isidor Zeuner
1 sibling, 0 replies; 18+ messages in thread
From: Isidor Zeuner @ 2014-12-01 10:42 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
Hi Gregory,
response below quote:
> > Since this attack vector has been discussed, I started making some
> > measurements on how effective it is to connect to Bitcoin using Tor,
> > and I found that the number of connections dropping to near-zero is
> > a situation which occurs rather frequently, which suggests that there
> > is still room to improve on the DoS handling.
>
> I'm confused by this, I run quite a few nodes exclusively on tor and
> chart their connectivity and have seen no such connection dropping
> behaviour.
>
> Can you tell me more about how you measured this?
>
When you say "running exclusively on Tor", what do you mean exactly?
Do you also connect or allow connections through hidden services?
I made outbound connections through Tor exit points the only way to
connect to Bitcoin, and increased the number of allowed outbound
connection in order to get more meaningful values.
Lately, I could see unusual behaviour at:
* 2014-11-28 13:14 UTC
* 2014-11-25 07:32 UTC
* 2014-11-24 13:06 UTC
Anything I should look into?
> [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 (and the behaviour of
> the system here is known and intentional). There are other mechanisms
> available for people to relay their transactions than connecting
> directly to the bitcoin network; so their choice isn't just abandon
> privacy or don't use bitcoin at all.]
>
I think this issue is more important than it seems.
Firstly, when running Tor-only, there are still attack vectors which
make use of the DoS protection deficiencies.
Secondly, if we tell people not to connect directly if they want
privacy, how do we ensure that these indirect methods will not come
with implications for their privacy?
Best regards,
Isidor
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
2014-11-28 0:45 Mistr Bigs
@ 2014-11-28 5:30 ` Gregory Maxwell
2014-12-11 11:51 ` Isidor Zeuner
1 sibling, 0 replies; 18+ messages in thread
From: Gregory Maxwell @ 2014-11-28 5:30 UTC (permalink / raw)
To: Mistr Bigs; +Cc: Bitcoin Development
On Fri, Nov 28, 2014 at 12:45 AM, Mistr Bigs <misterbg6@gmail•com> wrote:
> That's what I was trying to say... The researchers are deanonymizing
> transactions from non-Tor connected hosts. So why are we talking about Tor
> limitations in response to this? Shouldn't we be discussing how to address
> the issues in Bitcoin proper?
Because if the user does not use tor or an analogous infrastructure
(e.g. something else reimplementing tor's functionality) the user can
be deanonymized in many different ways.
At the end of the day, if I'm listening widely to the network, and
your host is regularly the first to hand me your transactions then I
can draw reasonably reliable conclusions... and this is true even if
there is a complete absence of identifiable characteristics otherwise.
And, on the flip side if the host is persistently behind tor, even
with some watermarkable behaviour, their privacy is protected. So
making sure that hosts can continually use tor (or similar systems)
should be the higher priority. (And, of course, not reimplementing
tor leverages the millions of dollars of investment and dozens of
subject matter experts working on that system).
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
@ 2014-11-28 0:45 Mistr Bigs
2014-11-28 5:30 ` Gregory Maxwell
2014-12-11 11:51 ` Isidor Zeuner
0 siblings, 2 replies; 18+ messages in thread
From: Mistr Bigs @ 2014-11-28 0:45 UTC (permalink / raw)
To: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 832 bytes --]
That's what I was trying to say... The researchers are deanonymizing
transactions from non-Tor connected hosts. So why are we talking about Tor
limitations in response to this? Shouldn't we be discussing how to address
the issues in Bitcoin proper?
M
On 11/27/2014 9:30 PM, Gregory Maxwell wrote:
On Thu, Nov 27, 2014 at 5:44 PM, <misterbg6@gmail•com> wrote:
I might be mistaken, but it seems to me this paper discusses unintended ways
of obtaining the IP addresses of clients involved in transactions on the
core Bitcoin network.
You're mistaken. :)
If a node is used exclusively via tor it effectively doesn't have a IP address.
(short of bugs of a class that aren't discussed here)
The paper is about fingerprinting approaches that probabilistically
connect transactions to hosts that you can already identify their IPs.
[-- Attachment #2: Type: text/html, Size: 1216 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
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-15 13:25 ` Isidor Zeuner
3 siblings, 0 replies; 18+ messages in thread
From: Wladimir @ 2014-11-27 11:27 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
On Thu, Nov 27, 2014 at 2:22 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
>> Since this attack vector has been discussed, I started making some
>> measurements on how effective it is to connect to Bitcoin using Tor,
>> and I found that the number of connections dropping to near-zero is
>> a situation which occurs rather frequently, which suggests that there
>> is still room to improve on the DoS handling.
>
> I'm confused by this, I run quite a few nodes exclusively on tor and
> chart their connectivity and have seen no such connection dropping
> behaviour.
In my experience the problem has always been getting bootstrapped.
Most nodes hardly give any hidden service nodes in their getaddr.
(this has been improved in master by including a set of hidden service
seed nodes)
But this assumes -onlynet=tor. Tor with exit nodes should be less
problematic, unless someone managed to DoSban all the exit nodes as
described in the paper (but I've never seen such an attack myself).
> Can you tell me more about how you measured this?
>
> [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 (and the behaviour of
> the system here is known and intentional). There are other mechanisms
> available for people to relay their transactions than connecting
> directly to the bitcoin network; so their choice isn't just abandon
> privacy or don't use bitcoin at all.]
Right, there's something to be said for splitting your own transaction
submission from normal P2P networking and transaction relay.
(esp for non-SPV wallets which don't inherently leak any information
about their addresses)
There was a pull request about this for Bitcoin Core one, maybe I
closed it unfairly https://github.com/bitcoin/bitcoin/issues/4564 .
Wladimir
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
2014-11-27 2:22 ` Gregory Maxwell
@ 2014-11-27 11:06 ` Mike Hearn
2014-11-27 11:27 ` Wladimir
` (2 subsequent siblings)
3 siblings, 0 replies; 18+ messages in thread
From: Mike Hearn @ 2014-11-27 11:06 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]
>
> [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.
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.
[-- Attachment #2: Type: text/html, Size: 1401 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
2014-11-27 2:09 ` Isidor Zeuner
@ 2014-11-27 2:22 ` Gregory Maxwell
2014-11-27 11:06 ` Mike Hearn
` (3 more replies)
2014-12-01 10:42 ` Isidor Zeuner
1 sibling, 4 replies; 18+ messages in thread
From: Gregory Maxwell @ 2014-11-27 2:22 UTC (permalink / raw)
To: Isidor Zeuner; +Cc: Bitcoin Development
> Since this attack vector has been discussed, I started making some
> measurements on how effective it is to connect to Bitcoin using Tor,
> and I found that the number of connections dropping to near-zero is
> a situation which occurs rather frequently, which suggests that there
> is still room to improve on the DoS handling.
I'm confused by this, I run quite a few nodes exclusively on tor and
chart their connectivity and have seen no such connection dropping
behaviour.
Can you tell me more about how you measured this?
[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 (and the behaviour of
the system here is known and intentional). There are other mechanisms
available for people to relay their transactions than connecting
directly to the bitcoin network; so their choice isn't just abandon
privacy or don't use bitcoin at all.]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
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-12-01 10:42 ` Isidor Zeuner
1 sibling, 2 replies; 18+ messages in thread
From: Isidor Zeuner @ 2014-11-27 2:09 UTC (permalink / raw)
To: odinn; +Cc: Bitcoin Development
Hello there,
quote:
> Please see also the following:
>
> https://cpunks.org//pipermail/cypherpunks/2014-November/005971.html
>
I agree about the severity of the Tor/Bitcoin issue, but I see no
point in bashing Bitcoin's financial privacy characteristics as
the linked pages seem to do.
Bitcoin can be useful as a part of a strategy to improve on privacy,
but it does not intend to be a run-and-forget solution for doing so.
A lot of issues found in this context can actually be traced back to
Tor's characteristics already known before. It's just that
Bitcoin makes Tor's deficiencies more measurable - before Bitcoin,
those interested in researching how Tor performs in an automated
context where a much smaller community. In the end, I guess both
projects can benefit from the research we can do now.
> Respect,
>
> - -Odinn
>
> Jeff Garzik:
> > I don't recall being contacted directly, but the attack has been
> > discussed. It relies on a number of conditions. For example, if
> > you are over Tor, they try to kick the machine off Tor, _assuming_
> > that it will fall back to non-Tor. That's only true for dual stack
> > nodes, which are not really 100% anonymous anyway -- you're
> > operating from your public IP anyway.
> >
Generally, it cannot be said that the attack vector described here is
irrelevant for non-dual-stack nodes. An attacker might not be able to
collect IP addresses of Tor-only nodes, but he can try to kick the
users from all Tor exit nodes he does not control, and proceed with
other attacks when a large number of Tor-only users connect through
his Tor exit node(s).
Since this attack vector has been discussed, I started making some
measurements on how effective it is to connect to Bitcoin using Tor,
and I found that the number of connections dropping to near-zero is
a situation which occurs rather frequently, which suggests that there
is still room to improve on the DoS handling.
Best regards,
Isidor
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
2014-11-26 13:51 ` Jeff Garzik
@ 2014-11-26 17:13 ` odinn
2014-11-27 2:09 ` Isidor Zeuner
1 sibling, 0 replies; 18+ messages in thread
From: odinn @ 2014-11-26 17:13 UTC (permalink / raw)
To: Jeff Garzik, Jean-Paul Kogelman; +Cc: Bitcoin Development
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Please see also the following:
https://cpunks.org//pipermail/cypherpunks/2014-November/005971.html
Respect,
- -Odinn
Jeff Garzik:
> I don't recall being contacted directly, but the attack has been
> discussed. It relies on a number of conditions. For example, if
> you are over Tor, they try to kick the machine off Tor, _assuming_
> that it will fall back to non-Tor. That's only true for dual stack
> nodes, which are not really 100% anonymous anyway -- you're
> operating from your public IP anyway.
>
>
> On Wed, Nov 26, 2014 at 2:47 AM, Jean-Paul Kogelman
> <jeanpaulkogelman@me•com
>> wrote:
>
>> This paper was just posted on reddit that describes how an
>> attacker can de-anonymize clients on the bitcoin network. It
>> mentions that the core devs were contacted prior to publication.
>> I was just wondering, how many of these issues have already been
>> addressed?
>>
>>
>> Paper (University of Luxembourg):
>> http://orbilu.uni.lu/handle/10993/18679
>>
>>
>> Kind regards,
>>
>> Jean-Paul
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
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=157005751&iu=/4140/ostg.clktrk
>>
>>
_______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
>
>
> ------------------------------------------------------------------------------
>
>
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=157005751&iu=/4140/ostg.clktrk
>
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCgAGBQJUdgpQAAoJEGxwq/inSG8CBCMIAI8IyyzxbhC0NVY8wyLXaHnW
um0HkmrP0bknL0ugjXDXHIBJmadH9uwOT5g1WpJ1siJbjm7nTNn2EXui8EKaX133
SkdZu0IVV5wDZB0OnIDxxx4cyuwNBWbxLh0boVCzydUlZaxQCx88SriKLNj4NrAT
oPBuOSL9Z/EsscO8PIh73+t7rdsAQo7koFcwVB8OgjKKATZpAgu4/hwBDoSnhv/U
F/X1EcQifg5j2DPmPmJo2/u9PmfHjgDUevw7qJOYNDFMPq4zhi6IC+x2aAXZg0rk
jHF79loJ5vueMaU6APVcIQ4izbyzU0y0JaY4Rukq0YkuXCMgZB8BJlS/BPntZdY=
=K2tn
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
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
0 siblings, 2 replies; 18+ messages in thread
From: Jeff Garzik @ 2014-11-26 13:51 UTC (permalink / raw)
To: Jean-Paul Kogelman; +Cc: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]
I don't recall being contacted directly, but the attack has been
discussed. It relies on a number of conditions. For example, if you are
over Tor, they try to kick the machine off Tor, _assuming_ that it will
fall back to non-Tor. That's only true for dual stack nodes, which are not
really 100% anonymous anyway -- you're operating from your public IP anyway.
On Wed, Nov 26, 2014 at 2:47 AM, Jean-Paul Kogelman <jeanpaulkogelman@me•com
> wrote:
> This paper was just posted on reddit that describes how an attacker can
> de-anonymize clients on the bitcoin network. It mentions that the core devs
> were contacted prior to publication. I was just wondering, how many of
> these issues have already been addressed?
>
>
> Paper (University of Luxembourg):
> http://orbilu.uni.lu/handle/10993/18679
>
>
> Kind regards,
>
> Jean-Paul
>
>
> ------------------------------------------------------------------------------
> 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=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
[-- Attachment #2: Type: text/html, Size: 2551 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper
@ 2014-11-26 7:47 Jean-Paul Kogelman
2014-11-26 13:51 ` Jeff Garzik
0 siblings, 1 reply; 18+ messages in thread
From: Jean-Paul Kogelman @ 2014-11-26 7:47 UTC (permalink / raw)
To: Bitcoin Development
[-- Attachment #1: Type: text/plain, Size: 414 bytes --]
This paper was just posted on reddit that describes how an attacker can de-anonymize clients on the bitcoin network. It mentions that the core devs were contacted prior to publication. I was just wondering, how many of these issues have already been addressed?
Paper (University of Luxembourg):
http://orbilu.uni.lu/handle/10993/18679 <http://orbilu.uni.lu/handle/10993/18679>
Kind regards,
Jean-Paul
[-- Attachment #2: Type: text/html, Size: 895 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2015-01-22 13:20 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-27 17:44 [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper Mistr Bigs
2014-11-27 20:30 ` Gregory Maxwell
-- strict thread matches above, loose matches on Subject: below --
2014-11-28 0:45 Mistr Bigs
2014-11-28 5:30 ` Gregory Maxwell
2014-12-11 11:51 ` Isidor Zeuner
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
2015-01-22 13:20 ` Mike Hearn
2014-12-15 13:25 ` Isidor Zeuner
2014-12-01 10:42 ` Isidor Zeuner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox