[tor-dev] Future Onion Addresses and Human Factors
biolizard89 at gmail.com
Sun Aug 9 07:26:58 UTC 2015
-----BEGIN PGP SIGNED MESSAGE-----
On 08/09/2015 06:54 AM, Jeff Burdges wrote:
>> I did a rough calculation about a year ago of how much it would
>> cost to buy ASIC miners that could 51%-attack Namecoin, and it
>> came out to just under a billion USD.
> Isn't the 51% attack down to a 20ish% attack now?
The estimate I did was based on Namecoin hashrate, not Bitcoin
hashrate. I assume that's the distinction you're referring to, though
you're not really making it clear.
>> Of course, a real-world attacker would (in my estimate) probably
>> be more likely to try to compromise existing miners (via either
>> technical attacks, extortion/blackmail/bribery, or legal
> Isn't 50ish% controlled by one organization already Is it not a
> particularly tight not organization or something?
Of Bitcoin or Namecoin? Definitely not in the case of Bitcoin (though
50% of Bitcoin hashpower was controlled by one pool, GHash.IO, a year
or two ago). Pools and miners are not equivalent, because if a pool
does something shady, it's easily detectable and the miners who use
that pool (of which there are many) are free to switch to a different
pool. F2Pool does have a majority of Namecoin hashpower at the
moment, because several other Bitcoin pools aren't mining Namecoin.
This is, to my knowledge, because those pools are unaware of the newer
Namecoin software (Namecoin Core) and had some problems with the old
Namecoin 0.3.80 code (which was deprecated many months ago in favor of
Namecoin Core). We're looking at reaching out to pools that aren't
mining Namecoin right now, and I certainly agree that it is not great
that F2Pool has a majority. If 1 or 2 other Bitcoin pools started
mining Namecoin, that would not be the case anymore. FWIW, I've seen
no evidence that F2Pool is shady in any way; they've been quite
responsive and supportive.
> Isn't the real world attack that you simply isolate a namecoin user
> from the wider namecoin network? That's cheap for state level
> I'd imagine OnioNS should have a massive advantage here because Tor
> has pinned directory authorities, who presumably help OnioNS
> accurately identify honest quorum servers.
It's doable to construct a Bitcoin or Namecoin client that
authenticates certain semi-trusted peers to retrieve blocks from, and
panics if it can't securely contact them. Electrum is an example of
this kind of protocol (though it does SPV verification rather than
full verification of the data it receives). This is a client
implementation issue (and one that I agree is important), not an issue
with Bitcoin or Namecoin as a whole.
>> An end user will be much more likely to notice when a Namecoin or
>> OnioNS name changes, compared to when a .onion name changes. So
>> this isn't really a clear win for .onion -- it's a tradeoff, and
>> which is more "secure" depends on which end users we're talking
>> about, and what threat model we're dealing with.
> This is false. Users must enter the .onion address from somewhere.
> If they go through a search engine, then yes the .onion address
> itself is hard to remember, especially if they visit many sites.
> Key poems address this.
> If however they employ bookmarks, copy from a file, etc., and
> roughly proposal 244 gets adopted, then an attacker must hack the
> user's machine, hack the server, or break a curve25519 public key.
> Yes, a search engine covers .onion addresses should ask users to
> bookmark desirable results, as opposed to revisiting the search
> engine, mostly for the protection of the search engine.
I think you will find that a number of users are unlikely to
exclusively use bookmarks and not use web links. Hyperlinks are an
incredibly useful feature which many users are not going to throw out.
From what I can tell, your argument makes certain assumptions.
Making other assumptions changes the result. Hence, as I said, "it's
a tradeoff, and which is more 'secure' depends on which end users
we're talking about, and what threat model we're dealing with."
- -Jeremy Rand
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the tor-dev