Topic: What is the right and fair way to stop Mike Hearn? - page 5. (Read 14093 times)

And Mike, you do recognise that you've not answered ANY of our concerns regarding externally issued centralised tokens (e.g. passports) - governments running hashes, forgeability, duplication, centralisation, low ownership in MASSIVE parts of the world.

Don't hand wave that 'people can get them if they want', or 'they're just optional'.

Do you recognise that your solution is completely counter to the trustless distributed nature of bitcoin?

I do want to thank Mike Hearn for coming into this thread and clarifying what, without context, sounds very troubling.  So, thanks, Mike.

But realize that supporting measures that break the fungibility of bitcoin (black/redlisting) have made you very untrustworthy to the bitcoin community.  Do you have any clarification of that for us?

It's quite latency sensitive now, but the low hanging fruit in terms of improving that hasn't even been touched yet.

Start with a new block message that only includes transactions hashes instead of full transactions and you reduce the amount of burst bandwidth needed by a factor of (size of a hash)/(average transaction size).

With a bit more work miners can broadcast most of the block in parallel with hashing so that the amount data they need to rapidly propagate once they find a valid hash is tiny and constant relative to the transaction rate.

You're glossing over this like it's insignificant.  In the UK, passport ownership is relatively high at 75%.  In the US, it's 30%.  In Canada, it's 60%. 

While it has been increasing in the US due to relatively new Canada and Mexico restrictions, most Americans will never get a passport if they are not travelling outside the US.  It costs close to $200, is a royal pain that requires several steps, takes months to get, and then expires in 10 years. 

While UK ownership might be high at 75%, I doubt that the US is a special case unless you think that only the US and Europe matter.  I'd like to believe that Bitcoin isn't just for Europeans or the US citizens. 

I'm aware that the USA is a special case and that's why I specifically mentioned it in my talk.  In other parts of the developed world passport ownership is much higher. The UK Passport office issued over 5 million passports in the last year alone, for a country of about 65 million people.

Anyway, any American that wants a passport can get one. And passport ownership there has been going up steadily over time.


I would not say that pointing a large directional antenna at somebodies pocket (how do you even know they have a passport in there?) and then breaking the BAC encryption on it would be classed as "easy".

Also, American passports have shielding in the outer layer so that can't work. Other countries rely on the encryption or on the active authentication system to prevent cloning. Countries that use neither extra shielding nor active auth presumably don't feel that this type of theft is actually an issue in practice. If times changed, they could upgrade.

I didn't get the rest of your post, sorry. You want an alternative MITM breaker that isn't this and isn't SSL either? Then what?


Great question! The talk was only 15 minutes (a lot of people were standing the whole time), so there is a bunch of detail that I glossed over.

The proof you present is proof you ran a program correctly. Thus the hash can be salted, memory hard or whatever you want to do. Now I think there is a legitimate issue here which is that the space of valid passports is not very large - even in the best case of 100% ownership it's O(size of country) so even if the hash is salted or whatever a government that wanted really badly to deanonymize its citizens who are running nodes could potentially brute force every single hash. This is especially an issue because a program that's being proved runs much slower than a normal program would. So there's some perhaps some more work to do here.

Of course it is not any different to the situation we have today where a government can just find every IP in their country that's running a node and go look the owners up via telcos. Even if you assume all nodes run via Tor it's not clear you can stop a government de-anonymizing you, because of things like traffic flooding attacks. And frankly the Bitcoin P2P network is quite latency sensitive, new blocks need to be flooded as fast as possible to minimize miner losses to orphan blocks, so it's unclear to me that the entire Bitcoin network will ever run behind Tor 100%. I certainly wouldn't predict it as a no-brainer future.

In short, whilst a dedicated government might be able to reverse the hash somehow, they already have other options that are unlikely to go away, and the hash does stop everyone else from learning who you are which is still pretty useful (indeed, a basic requirement).

Bitcoin Core Developers according to http://bitcoin.org/en/development

Satoshi Nakamoto
Gavin Andresen - [email protected]
Pieter Wuille - [email protected]
Nils Schneider - [email protected]
Jeff Garzik - [email protected]
Wladimir J. van der Laan - [email protected]
Gregory Maxwell - [email protected]

edit: typo

Maybe I'm missing something, but what's preventing a government from running the hash function on all the passports and de-anonymizing all the hashes? They own the passports database after all.

What pass themselves off as multiple separate nodes are actually controlled by the 'same guy.'  To answer your other question: yes.

You got started out on the wrong foot here by mis-stating the problem.  A straw-man based chain of reason is invalid (though not necessarily flawed) whether the straw-man is erected out of ignorance or malice.

Your mistake was recoverable by arguing that 'good' meant simply that it was not a dummy/army node.  Instead you doubled down and argued that 'good' meant that the guy had political motivations which matched your own.

---

Here's the deal (as I see it...)  This is not a terribly difficult problem _YET_ because one need only to hit a few legitimate nodes in a random sample.  Even a large number of 'bad hits' is not a huge problem.

At present there are a decent number of nodes.  The trouble which I'm sure that Mike perceives (he being unusually prescient) is that when the goal of having a handful of supernodes constituting 'peers' in the 'p2p network' is achieved the problem becomes more difficult.  This because there simply is not a large pool from which to obtain a sample.  At that point clients can just hard-code a known googd 'peer' into one's client, but we got to get there first without scaring people away by getting raped.

Mike's idea of using passports was not aimed at the problem of not being able to ID users by mapping them to a real-world identity.  (He'll work on that problem later I'm sure and probably already is, but separate to this issue.)  The thing is that he forgot what dopes most of the community are and got blindesided by a mis-conception that he probably didn't really anticipate.

---

OTOH...a lot is made about the privacy of the node operator (peer/server) vs. the SPV (client) via the ZKP stuff.  Although any (optional) privacy is better than none, it seems to me like a bit of a 'so what?'  Not much is made of the client side operations.  I'm left to surmise that the client is going to have to check back with Big Brother from time to time (always?) to ensure that the server (and who care who the fuck he is) has not issued some bullshit sig?

If so, that's pretty nice data to draw up a map of client usage.  Particularly if the data can be correlated with that of the server node (which is highly likely in a lot of cases.)

 - edit: slight grammar.

Please stop associating us old cypherpunks with your idiotic religion. Schwann was not representative of the rest of us.

Ummm, no, Mike, they don't. 

"Of the 308 million-plus citizens in the United States, 30% have passports."  (CNN)

I couldn't find stats on the whole world because Google, Yahoo and Bing only returned stats on Americans for some reason.  But, I have a hard time imagining it being higher in third-world countries. 


I get what you're trying to do, Mike.  You want to somehow speed up the validation of anonymous transactions.  But, trying to include ANY aspect of identity to validate an anonymous transaction is, as others on this thread have suggested, a very bad idea from the start. 

Let's pretend like everyone in the world has a passport.  One very big issue today with RFID is how EASY it is to STEAL the info on the passport you're presuming isn't stolen.  If your protocol extension ever became popular, you'd just give passport info thieves yet another reason to copy that info.  Honest people may not have more than a couple of passports.  But, dishonest people can have thousands of copies of passports of honest people without anyone knowing they have the copies.  And dishonest government organizations or people?!? 

Let's set aside anonymity for a moment.  Isn't this a very round about way to try to verify that a transaction is valid?  You use the man-in-the-middle attack analogy, which is usually used for plain texting a cipher.  What the man-in-the-middle attack relies on with SSL is that only one side is providing a certificate.  This attack fails when BOTH sides provide a certificate, and both sides validate the other side. 

While I hate using this SSL analogy at all in the discussion of verifying Bitcoin transactions, because it is not even close to being the same thing, the bottom line is you can mathematically verify communications in a way that prevents a man-in-the-middle attack.  Bitcoin is in a position to offer that, unlike SSL.  SSL doesn't because of convenience, and because it ultimately relies on identity and third parties in the HTTP world, which, ironically, have made SSL expensive for non-revenue generating entities -- like people.  That is, it is expensive to purchase a cert that can be validated by a "trusted" third-party. 

But, I digress.  In Bitcoin, you can prevent a man-in-the-middle without resorting to a broken identity third-party based barely trustable system like SSL over HTTP. 

So, beginning any transaction integrity validation scheme with public identity to increase trust, knowable or non-knowable, just opens a huge can of worms and increases the risk to the Bitcoin network and its users rather than lowering it. 
 
   

That's true. But getting back to the context of what Mike was talking about - this is about validating nodes in the network and ensuring they aren't being hijacked to steal your transaction data.

So what we need is a 'one node one vote' system - a way of identifying nodes are real with respect to others in the network.

My personal feeling is that a 'proof-of-connectivity' relying on data transmission rates and time-stamping might be a way forward. For example - if I gave you a starting point such as a nearby train station, and told you times and turns you could identify my house with 100% accuracy each time.

If you could start with one node and probe a map of its connectivity to others nearby, you'd end up with a trust less connectivity map accurately identifying that node.

Or imagine a 'Stargate' model, where a sequence of latencies to nearby nodes produces an unforgeable code/identifier. Each block originating from a node could even be labelled with its 'gate address'. Furthermore, this could generate a node map that's permanently encoded into the block chain, growing organically with the network but also allowing the identification of spoofed nodes (for example, nodes that suddenly appear and have a fixed time lag to one particular group of nodes that it's trying to spoof, but 'wrong' latencies to other supposedly nearby nodes).

Another possibility of this system could be to map out mining pools and thereby help resist 51% attacks.

Although I agree with you, I don't think it will ever be truly solved, because as we discussed earlier you can't replace one cpu one vote with one user one vote, without a definition of "user", which requires trust of some kind. So maybe distributed is possible(?) but I can't see how trustless is.

Well, first, that is from more than 10 years ago Also, the depth of the problem doesn't go against what I'm saying - I'm saying exactly that the problem is deep (architecture and motivation of users) not shallow (UI).

Whilst I'm not quite as animated about the subject, I do think that moving from a trust-less to a trusted model is fundamentally wrong.

If we can't solve this issue in a distributed, trust less fashion then we should delay any implementation.

Mike, thanks for joining this thread and helping us to understand your position on some of your public statements.

That said, I have some context catching up to do.  But, after just popping over here after reading that [Suspicious link removed]j.com/digits/2014/01/24/microsoft-backs-out-of-sponsoring-anti-rsa-conference/?mod=WSJ_hpp_MIDDLENexttoWhatsNewsForth]Microsoft is pulling out of[/url] Trustcon, and reading your post, I couldn't help but crack up and be a tad concerned. 


You think large governments get security right?!?  REALLY?!?  WOW! I don't even know where to begin here.  You trust big government to solve complex security issues because you believe they are highly incentivized?!?  That's your premise for the foundation of trust?  ROFL!!!

Actually you don't need to run the PGP experiment yourself. You can just read a usability study of PGP. It makes it pretty clear, I think, that the UI issues with encrypted email run pretty deep.

Ah. The assumption is it's easier to steal lots of geographically distributed IP addresses than passports.

Of course, if lots and lots of people used this scheme to manufacture themselves an anonymous identity, then you might start seeing botnets steal those identities as well. For just node operators, it doesn't matter so much. If this idea became widespread for other purposes, we might end up back at square one.


I don't have any good data on it, especially because most countries are in a transitional period where non-chipped passports are still valid.

Yes, you're quite right, it's very limited. In introducing it to non-technical friends I've seen some frustration and even panic I just don't think the problems are about badly written software. The stuff you mention about cross device limitations are very true, but that comes out of exactly the point I was making earlier re: why ssl is so much better, it's because there's no need to sync keyrings. In client-server you can just let the server do all the hard things.

Pick three random non-experts and try introducing them to the concept of encrypted email.

Walk them through the entire process of moving away from the workflow they use now and into a new one that includes Thunderbird and Enigmail.

Make sure to cover the concepts of key signing; what it means, how to assign trust, and how to actually do it.

Remember that modern users don't read email on a single device - they've got desktops, laptops, tablets and phones and are accustomed to things just working no matter what device they're on. Ever tried to synchronize keyrings and trust settings across multiple devices before?

Do that, and then come back here and say the UX for encrypted email is just fine.

It's not just about the mechanics of actually encrypting and decrypting messages, any more than driving a car is just about how easy it is to fill the gas tank. it about the entire process.

Fair enough. I'm not making an argument for bad UI I'm more making the argument that UI is OK, and isn't the cause of under-adoption. Is UI really so bad? Enigmail seems fine to me. From what I've seen of Kryptokit (I use Firefox so I don't have it yet), it looks good. Do you think modern day PGP/GPG software is that badly written?