>
> 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 t
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 conn
[...]
> > 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 geta
[...]
> 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 leverage
>
> 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 wi
> >
> > [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
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,
On Fri, Nov 28, 2014 at 12:45 AM, Mistr Bigs 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 Bitco
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, Mistr Bigs 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 effect
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 ow
On Thu, Nov 27, 2014 at 2:22 AM, Gregory Maxwell 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 r
>
> [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 populat
> 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 t
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 ca
-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 condition
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%
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):
18 matches
Mail list logo
