Bitcoin Forum

London, Tuesday, 21st January at Club Workspace, Clerkenwell.  Coinscrum host an informal evening with presentations from Circle’s CEO, Jeremy Allaire, and CTO, Sean Neville. Also core Bitcoin developer, Mike Hearn, will be joining Jeremy and Sean and will also be taking to the stage.

http://www.iamsatoshi.com/coinscrum-networking-evening-circle-london/

BobAlison (summary):

What's ahead for Bitcoin? Here are some highlights from the video:

    HD Wallets, used by Trezor and others
    Time to scrap addresses. They are too limited and problematic.
    The Payment Protocol to replace addresses. Supports refunds, memos, receipts, proof-of-purchase, and digital signature.
    Minimum fee will float. Payment Protocol to allow receiver to pay fee.
    TOR by default (ambitious goal). Encryption for free and other advantages.
    WiFi hacking countermeasures. How do you know you're connected to the real network and not a spoof? Localbitcoins seller can trick you into connecting to his/her own wifi network at a cafe and cheating you.
    TOR disadvantages. Tor hides node IP addresses. How do you know you haven't connected to 10 different nodes that area actually all the same computer?
    Proof of Sacrifice. Node burns coins to make it costly to spoof the network.
    Proof of Passport. Goal is to make network spoofing harder. Goverment-issued passports contain an NFC chip. Data digitally signed by governments and can be read with standard hardware. Didn't understand the rest.

"Proof of Passport" WTF WTF WTF
He can't be serious.

Before people go on another witch hunt.

It's a zero-knowledge proof. Doesn't reveal anything.

In order to run honest nodes, you either needs to make it expensive (and slightly prohibitive), ie proof-of-sacrifice, or cheap (using other forms of identification that is expensive to forge), ie proof-of-passport. With zk-snarks, you can prove you own a passport, but reveal nothing. This isn't the best way, due to possible government intervention, but it is a practical, cheap, anonymous alternative.

There could be other ways to establish identity, OR to establish honest nodes.

Come on, there is zero problems with dishonest nodes. Sybil attacks are very hard to pull off and there are other easy ways to compete against it. (e.g. just using the hard coded seed nodes or downloaded lists of trusted nodes on insecure network connections)

Maybe now "Proof of passport" is zero-knowledge proof. But who gonna guarantees it stays this way. Nobody! As it will be be changed for sure sooner or later.

This is BS. This would have no chance if Satoshi would be still here. It's a big disgrace to his invention.


If Mike Hearn stays Bitcoin coder, we will get a Paypal-version of bitcoin for sure.

First: he pushes for blacklisting
Second: he pushes for SSL and extern CAs
Third: he pushes for everybody to proof of identity by showing their passport

I have no imagine what fourth or fifth will be.

This is ill.

proof of passport is anonymous to individuals as the serial numbers are not names/addresses and individuals do not have access to the government databases. but governments can use their database to identify people.

this is also going to make bitcoin harder to use for individuals. imagine it this way. would you sign up to pay pal if they asked you to not just make a username and password, but to also input your passport numbers.

i know my parents and a few other relatives don't have passports. so even if they wanted to sign up to a payment gateway, they cant because it asks for info they do not have.

and also, who verifies that the passport is valid.... this would involve a government agency controlling user accounts.. by them veryifying passports to allow or disallow people from having bitcoin accounts.

mike hearn and luke jr are not good people when it comes to anonymity and ease of use for the individual.

I have a database dump here with 200.000 complete german data records of real people (name, address, date of birth, place of birth, ....) with correct passport number and issuer office.
I will instant release this anywhere, if this proof of identity becomes part for Bitcoin.

You guys CLEARLY didn't even watch the video. So quick to jump to conclusions. Typical.

It's not required. AT ALL.

If you have an SPV client (ie Android Wallet, or MultiBit), it has to trust the nodes they are connected to (for 0-conf transactions). If you have an Android wallet, there are usually 2 ways to improve this: increasing trust-less interactions (although I'm not sure how) for SPV clients, OR improve the trusted-ness of the SPV clients you are connecting to. As Mike states, spoofing this isn't difficult. To make sure spoofing is decreased you have submit a proof that's expensive or hard to forge. A passport is only 1 such implementation. Thanks to wonderfully complicated maths of zk-snarks, it is ANONYMOUS. And you don't HAVE to use this method, then you'll just have to be content to possibly be defrauded OR you just have to more precautions to make sure you are connected to 'right' Bitcoin network: waiting for confirmations, and shuffling networks (wifi, 3g)/nodes. It's up to you.

Educate yourself, please. You also seem to miss Mike's Tor proposal. Or his proposal on merge avoidance, both INCREASING privacy.

P.S. If I'm wrong on the technical implementations, please correct me, that's how I understand it.

Hearn is a run down government whore. Nobody cares what he has to say on any topic. No project associated with him will ever get anywhere.

End of story, really.

Hi everybody,

I was at the event at which Mike spoke and the proposal seemed pretty clear to me.  Here's my recollection of how he laid it out.

1) We need to improve protection against certain classes of Sybil attacks.  That is: we need to make it harder for one "actor" (person, entity, whatever) to masquerade as multiple "actors".   e.g. if I am connecting to eight peers, I'd like some reassurance that they are controlled by different people and not actually the same person pretending to be eight different people

2) There are some interesting ways of achieving this.

3) One way is "proof of sacrifice":  you could devise a scheme whereby creation of a unique "node identity" (my loose term - Mike didn't use this phrase) requires visible destruction of some small number of satoshis.  This is easy for you to do if you only want to present one such identity to the world but very expensive if you wanted to create 10,000 different identities.  So.... if you had this system, a client could make sure to connect to nodes with different identities and they could be more sure that they were controlled by different actors.  Not perfect but it would probably be OK.   Big problem though:  nobody wants to throw away their money!

4) So is there another way?

5) Mike's insight:  why don't we ask ourselves this question:  "what do most people have one of and would find exceedingly difficult to have 10,000 of?"   I guess some answers might be a house or a car or something like that... but Mike added the additional condition: "what do most people have one of and would find exceedingly difficult to have 10,000 of and *which they can prove they have over the internet*?"

6) He then pointed out that the spec of most modern passports calls for them to have an embedded chip and for the chip to have the option of including a private key that can be used to sign arbitrary challenge messages.

7) A ha!  So we already have a widely-deployed infrastructure that maps (roughly - not perfectly) one person to one private key.

8 ) So.....   you could come up with a crypto scheme that allowed you to create a node identity that everybody could see could only have been created by the holder of a passport... and which would be different for each person.... but it would not reveal anything about the person or their passport... just that the controller of that node *has* a passport.

9) Unfortunately, most passports don't implement the signing function so it looked like the idea was dead in the water

10) However, a paper presented at the May BTC conference showed that it may be possible to work around this problem and still achieve the same ends (the details are complicated and I didn't understand them).

Bottom line:  this part of the talk was all about a really interesting approach to preventing a particular type of sybil attack.   

To be clear... when I talk about node identities and the like, I'm not talking about real-world identities of individuals... just some random token associated with a node that is the same for all nodes controlled by the same actor and different for nodes controlled by different actors.

It's funny. Five years later, and we're back to the ancient issue of Sybil resistance. Nakamoto managed to solve that for "voting on the history" applications, but now the gossip network itself is at risk.

Isn't that odd? Proof of work works. Is it really that difficult to say something like, okay, if you can hit a target that's some preset fraction of the network difficulty, you get to play? Or is there some other issue there, that would prevent that approach from working?

So the thing about these proposals is that they're all about the gossip network, not the blockchain. And the thing about the gossip network is that mediators and intermediaries are easy to create. A Bitcoin gossip network that only allows people with passports to be a full node is worrisome to me too. But - and this is key - all it takes is one authenticated network user who then allows non-passported connections for anyone to avoid this. And there will be plenty of people (you are one example!) who will be unable/unwilling to create a passport proof, so that gossip network will have plenty of peers and we can continue as before.

Good. Anything that can increase the default anonymity of the system is a win anyway, as far as I'm concerned. If these people don't even know what is a "Tor", they'd never have used it, and the whole network suffers from the leak of their information. Tor by default is herd immunity. Not revolutionary, but a good idea.

The problem is you need only 4 and not 10000 because Android Wallet and MultiBit connect to only 4 nodes. Someone who wants (and is technically skilled enough) to rip of people with fake nodes during large zero confirmation cash transactions (what a stupid example anyways, who on earth is doing large cash-for-bitcoin transactions with zero confirmation anyways?) can easily have 3 (or 7 or 11) friends in his gang with (anonymous!) passports to help him.

This idea is so ridiculous.

And on top of that the most dangerous and most likely enemy, the government itself, can easily fake 100,000s of passports.

Proof of work is done by miners, the problem does not exist in the frst place, thats why global consensus is established by the miners, thats what confirmations are meant for.

To be fair to those of us on the more sceptical side (but who remain civil), this is not really a matter of insight. It's not as if no one else who is thinking about identity management understands that governments have pre-existing databases (although Mike's investigation into NFC obviously raises the value of his argument). It's that we consider it a really bad fit with decentralized cryptocurrency. What some people are afraid of, rightly or wrongly, is that the use of such an identify would become de facto if not de jure required.

This is not possible. Its not even possible to **define** this problem because you cannot come up with a definition for "actor" or "controlled". And its not needed anyways because Satoshi invented the block chain.

Sorry - not my intent to imply a lack of insight elsewhere!

And I'm acutely aware that my write-up is based on two-day-old recollections so apologies for the sketchiness of some of it.

I have to agree. It might look, superficially, as if such a system should work, but I wouldn't trust it as far as I could throw it.

It's not about attribution of an idea, I'm not worried about that (nor is anyone else, I'm sure), it's about whether the idea has merit. Trusting government issued identities is potentially very dangerous (because of both counterfeiting - the technical concern, and corruption - the political concern).

Yeah, that's the right way to protect from a Sybil attack.

Sybil attack:
Can somebody explain me, how a person can go into a cafe and connects to a not trusted WIFI, buys the bitcoin and leaves without one confirmation? Do people nowerdays not have internet access without WIFI everywhere (except maybe, when you are in a foreign country. There you pay a few cents for one MB)?

I don't really know, if this scenario is realistic.

Anyhow, if someone what's to prroof with his passport, that he is a trusted node, where is the problem? This is not required...

It's unrealistic and stupid, it's made up just for pushing this anti-privacy technique.


The problem is Mike Hearns mindset. How can he think about such stuff, given the history and origins of bitcoin and that the vast majority of the community doesn't want that.

So this kind of simulated network can spoof a payment but can not spoof a block confirmation?

Why is it that they cant spoof a confirmation btw (for a SPV client)?


Anyway, if that is the case, then it does seem like a insignificant issue. And there are probably easier and better ways to solve it.

Looks like Mike Hearn wants to solve the double spend problem. Maybe someone should tell him that its already solved.

Because SPV clients check the block chain.

The problem is that blocks arrive unpredictably. It's not uncommon for there to be an hours wait before the next block. So for many practical scenarios the block chain is not good enough (you still need it, but it's just not a total solution).

Note that the wifi hacking attacks can be "solved" using Tor. I put solved in quotes because Tor solves it by being more centralised than Bitcoin is, so whether this is a satisfactory solution is arguable.

You can also solve it by using your 3G connection and trusting your cell carrier, but that's also solving via centralisation. I thought people in this thread hated governments and corporations? Saying "just don't use wifi" seems like a rather statist solution ;)

There is only one authority that could ever be allowed to issue stuff like passports or certifications or hold elections and publish the results and this is the block chain!

The Tor project is rewarding long running nodes the "entry guard" status and once a node is elected and promoted to that status its recorded in their golbal consensus. their consensus is a fixed centralized consortium of servers run by the Tor project. We have a global consensus too, if we had the equivalent of "entry guards" it would be recorded in the block chain.

How about this: proof-of-uptime: instead of proving a sacrifice how about rewarding long running nodes or nodes that have relayed a lot of transactions for a long time with colored Satoshis to a dedicated address of this node. Upon connect the node would would sign a response to a challenge with this key/address and the other node can then look up the "trust"-level and the age of this address in the block chain.

This is only an idea. It still has to be refined, for example the SPV client needs to query all these proof-of-uptime tx for a new node (and check them against the block headers) if it has not yet seen this same node before, etc. but this is the general way I would like to see such kinds of problems be approached and not the cheap way of asking a central authority to do it for us. If we wanted a central authority we could ask the foundation to run a server for us and would not need the block chain anymore at all. Then we would have invented PayPal.org.

We are making a lot of propaganda of how useful a global decentralized trustworthy ledger is and how all kinds of important stuff can be recorded and certified there because we have finally solved the consensus problem and now we have something important that needs to be recorded or certified in a secure and trustworthy manner and the first thing Mike comes up with is invoking the government to do it for us instead of using our own cool new technology of global consensus.

There are two reasons that kind of centralisation doesn't bother me - (1) the trusted third party is impartial and (2) it's still distributed as one can use any one of a number of parties, different ISPs, networks, or use websites or nodes with ssl certificates to do the same job of giving a trustworthy report. It's (2) that's most important of course, because without the distribution, trusting one party gives them too much power and then (1) wouldn't really apply anymore.

As a concrete example I would, for now, trust blockchain.info over https to report the existence of an unconfirmed payment, acting as a cross check against whatever my client is telling me.

Hm and to get a trusted node, could we not just use the they key point of Bitcoin itself? A node, that relayed a certain amount of blocks the last 24hours (or maybe month), is not a made up node. Noone can just make up such nodes out of the thin air.

Or would it be some kind of DDOS when everybody connects to the same node?

The last 4 days there where 111 different IP addresses which relayed a solved block. Would that be enough for such special cases like buying a bitcoin with local bitcoin and going out with zero confirmation?

Yes, obviously having a trusted node solves the issue as well, which is why b.i and Electrum aren't so vulnerable to this attack. They trade off centralisation against having no sybil attacks.

Re: proof of uptime. The question is what measures the uptime. A wallet can reconnect to nodes it used before (it can become "sticky") if they seem to be long term nodes, but this requires care.

Firstly it'd require giving each node a long term key so connections can be authenticated. We talked about using SSL (without certificates) between P2P nodes and I still like that idea, but Gregory pointed out that OpenSSL is huge and complicated and people worry about exploits. Tor for SPV avoids that problem because it's all pure Java and just client code anyway. We could do an ad-hoc Bitcoin specific authentication solution though.

Secondly we'd have to be careful about load balancing. Right now SPV wallets get sprayed across the network by the DNS seeds. If wallets kept reconnecting to nodes they used before because they were long-term and therefore more likely to be good, you could end up with wild load imbalances. Tor has some experience with this.

Thirdly, we have the question of what you do if you can't reach your preferred long term nodes. If you try to connect and they aren't there anymore, you can easily go find new nodes .... but now you're back to having a sybil attack.

These problems are really hard. Remember that the "zero knowledge proof of passport" idea doesn't rely on uploading or publishing your actual passport data/identity anywhere. You provide a mathematical proof that you have a passport, but that doesn't give anything away by itself (billions of people have passports).

This guy scares the hell out of me.

I don't see anything revolutionary here. Who cares about such "passports" it just won't work, idea is not bad, but implementation is impossible in current environment.

There are many ideas around so don't panic please, many more will appear.

Furthermore speech about security was mostly ok (especially mobile wallets and Wifi), but Mike ideas are not final and I don't feel that he is able to force them against our will. So please don't make any personal attacks here it's childish.

Centralisation is diametrically opposed to the central ideology of the zero-trust, distributed nature of bitcoin. Trusting any third party now is a slippery slope to further centralisation and control later.

Don't put words in our mouths. I object to the heedless abandon with which you propose solutions to what you perceive to be bitcoin's problems with blatant disregard for the opinions of the wider bitcoin user base and the spirit of freedom upon which bitcoin was founded. You seem to want to turn bitcoin into a draconian, quasi-paypal system. Your vision of bitcoin's future seems antithetical to the whole purpose of bitcoin.

I understand that bitcoin needs to evolve from Satoshi's original client. Yet to myself and many of us, your "solutions" follow the same trajectory of hubris, folly, and greed from which many of us are attempting to distance ourselves by using bitcoin in the first place. Might as well go back to SWIFT, paypal, and visa/mastercard.

Mike, you have some serious explaining to do.

When we talk of centralization, we're not necessarily talking about 3G or Tor. Yeah, such aspects need to be addressed, but don't miss our point. We're talking about your proposed blacklisting and passport ideas. i.e., Censorship or the means to enact it, and letting other people have more and unnecessary control over our money. Why should anyone but me get to decide whom I can transact with?Bitcoin is a powerful tool that greatly promotes self-reliance and people "being their own bank." People see this, they love it, and they feel you're attempting to take this newfound freedom away from them.

Moreover and to the point, centralization creates weakness by having a more centralized point of failure.

MarketNeutral - thank you for putting that into words.

Mike, if you believe 'billions of people have passports', you're very misinformed. Fewer than 50% of the Japanese and US populations hold passports - two of the largest economies in the world.

You push this need for an external token, which goes against the core values of bitcoin. If you can't come up with a solution that is in keeping with the ideals of bitcoin then I'd rather you didn't propose one at all.

Your answer had better not be along the lines of 'you don't understand' or 'it's only optional' or 'well why don't you code it then'.

This idea should be dead in the water because it is based on Mike's assumption that everyone has a passport.  In America, only 30% of people have a passport.  I imagine it is lower in many other countries, and higher in some, such as where Mike is from.  

What baffles me is that he's been studying the passport idea for 6 months, but it only takes 5 minutes to Google up the low percent of people using passports.  Unfortunately, Google, Yahoo and Bing will only give me American statistics -- whether bias on their part or lack of info elsewhere IDK.  But, still.  

Shall all nodes be concentrated in the UK or wherever passport use is high, and be limited in countries where passport ownership is very low?  

I'm against this for many reasons.  But, I'd think that the low rate of passport owners would be enough to kill it without 6 months of analysis and code being written.  What concerns me is that this logic hasn't killed this idea, yet.  

I guess that Mike thinks that 2/3 of Americans live in Iowa.  

CNN (http://www.cnn.com/2011/TRAVEL/02/04/americans.travel.domestically/)
Forbes (http://www.forbes.com/sites/andrewbender/2012/01/30/record-number-of-americans-now-hold-passports/)

For those outside the US who wonder why only 30% of Americans have passports, besides the high cost of travelling across the ocean, most Americans are lucky if they can see half the wonders of America before they die.  Also, before 9/11, US citizens didn't need a passport to travel to Canada or Mexico. 
 

Too bad he said nothing about reducing/trimming the blockchain size.

Instead he talks about bloating the blockchain even more. Maybe I missed something but with these feature not only miners can easily include child pornographie into the blockchain but also every normal user? Why is this not an issue?

And what is with all the sybil talk?
But I like the idea of Proof of Sacrifice.

Again, I think you misunderstood the whole concept. Having a passport is not a requirement, but if I am using an spv wallet, I'd like to connect to someone that is authenticated using a passport so I know I'm not being a victim of a sybil attack. For this system to work only a minority actually needs to run such a node.

I, for one, am grateful someone is thinking outside the box. Nobody said this is the best possible solution but it's a step forward in solving a problem.

And what happens when we decide that people with Zimbabwean passports, or Venezuelan ones, or Gambian ones, or Tibetan ones, are just not allowed to run nodes anymore?

ANY centralisation or requirement for a centrally-issued external token is risk that we're beginning down a slippery slope towards blacklisting or worse.

Yeah, I agree.  At a minimum, it's discriminatory against those who don't have a passport, which is dividing the bitcoin community up.  Bitcoin needs to remain a trustless network.

In addition to Mike clearly incorrectly assuming that everyone outside Iowa has a passport, his proposal is based on other assumptions that are just false:

Ass. 1> Only the government has access to the database.  

He's ignoring how easy it is to collect this data with an RFID reader by just hanging out at an airport (https://randomoracle.wordpress.com/2012/08/27/reading-the-us-passport-using-an-android-phone-overview/).

Ass. 2> People only have 2 or 3 passports, limiting their ability to fake many nodes.

Honest people with iPhones will be limited to 2 or 3 passports.  Referring to #1, people with RFID readers or NFC equipped Android phones can have thousands -- and they are likely to be in the dishonest category, the same people who would simulate a network.  

Ass. 3> Governments can be trusted.  

Is anyone outside the US reading about how the NSA deliberately weakening encryption at the RSA (http://www.zdnet.com/rsa-conference-walkouts-set-up-rival-event-following-nsa-row-7000025383/)? And how one man walked out with nearly all the US Government's best kept secrets from the most protected division of the world's strongest military?  

  

This seems to be a basic assumption that everyone from the most fresh newbie to Gavin takes as gospel.

I say, 'not so fast'.  The basic structure of the original implementation (which we are still in) has proven pretty useful, and I don't think it can be written off as being valuable due simply to future expectations.  I think it is useful and trusted because it is still difficult to assault, and this because the stand-alone core infrastructure is operable in a very widely distributed manner.

A series of 'off chain' solutions (like BitPay, Coinbase, Mt. Gox, vendors like TigerDirect, etc) riding on the back of what we have currently has the potential to scale.  It would be 'SWIFT, paypal, and visa/mastercard' but for one very unique difference:  The core value store would not be under centralized control.  And people could still keep their lifes' savings in a paper wallet if the so choose.


There is room for a lot of 'centralization' at the second tier level where individual failures do not threaten the entire system.  BTCChina is a wonderful example of this principle.

This is a very specific proposed use of the bitcoin ID protocol, government passports are not required if you don't want to use them. Mike's just advocating a state dependent usage in the way you'd expect him to, but the base technology for this is equally good for stateless ID's too. In fact, it gives you the ability to create a form of ID that's less corruptible than any state run scheme. And you can choose how you structure it for yourself, and others can accept that as valid as they choose (but hopefully on some basis of how well it identifies you in an objective way  :D)

Question for Mike or anyone else who knows about this stuff:

What about a scenario brought up by a reddit user: a hotel clerk in a tourist destination handles a hundred international passports in a day. Is there some way they can surreptitiously grab a signature from each of them and use them for an attack?
So I tried an app out with my phone and it read the biometric,photo and ID details fine. The security info says the signatures are OK but it seems there is no "Active Authentication", meaning the passport could be cloned. Apparently that's the common situation according to this (http://www.cs.bham.ac.uk/~tpc/Papers/PassportTrace.pdf).

Without active authentication the system won't be defended against the hotel clerk attack, is that correct (because there is no nonce provided from the reader)?

Isn't necessary.

There were already three announcements (just on this forum) that big database dumps of x00.000 real passport data records with signing keys (if holder applied for passport with keys) will be released if this stuff doesn't stop.
It's known from most countries that only 5% till 25% of the passports are signed. Reasons: people don't want that and passports with keys are more expensive in applying fees. People who dont applied for keys get passports contain that an empty or dead chip, depends on country.

TruckStyling, thank you for bringing this up.

Centrally issued external tokens are inherently corruptible. This is why bitcoin exists in the first place - to transfer value in a decentralised, trustless manner.

If Mike Hearn cannot think of a means of trusting nodes that does not require a zero-trust, decentralised solution then I suggest he waits until someone else develops one.

Several posts on reddit indicate lists of passport numbers exist. If this is true, it would be trivial to obtain a large number of proof of passports.

And I am really struggling with the problem that this is supposed to solve. Mike gives an example where someone enters a public place, and connects to the internet using a random wifi hotspot. This hotspot is then not a real hotspot but a fake one set up for this man-in-the-middle attack. It creates a simulation of the bitcoin network with fake nodes to trick the connected clients that they are connected to the real network. A transaction by the client would seem to have gone through fine, however it would never be sent to and confirmed by the real nodes.

So, for this attack to work, someone must be tricked to connect to the internet through a malicious provider, and chose not to verify adequatly whether his transaction has been accepted by the network.
I think this attack vector is difficult to execute because it relies on a naive and careless user connecting through a malicious link. Tricking a node into connecting through a malicious link is already an aspect of this attack that is difficult to carry out on a large scale anyway. And it seems that the proposed solution does not resolve the issue at all.

Indeed, there must be a better way of making it impossible to impersonate previously seen peers, up to a point where this attack becomes unfeasible. For instance, by implementing a challenge-response between nodes, such that nodes can verify that a node they connected to a month ago is still the same node now and not part of some instant simulation. Do this for a couple of nodes, and in this way it can be verified that at least some nodes (ones that had been seen before) are the same one as during the first time a connection was set up with them. This would require a man-in-the-middle attack using a simulation to convince a node to send its transaction while only connected to nodes it sees for the first time. A node that usually sees a number of known nodes would be alerted by this and can refuse to send the transaction, especially when connected through a previously unseen (wifi) internet link.

Sorry for blatantly reposting my reddit comment on this issue, but I care about it.

We are talking about new relative node trust options on this thread (https://bitcointalk.org/index.php?topic=429264.180).   

Our setup is we don't want any external dependency, third parties, or general human trust.  Obviously, you can't completely evade the concept of "trust" in this problem, but you can make your solution depend on the trustless network instead of externally or on people-based attestation.  You can develop relative trust based on context using facts derived from the Bitcoin network itself. 

I'd create a new thread, but we're still waiting for Mike to say he's throwing out the ePassport idea.  Until then, we're determined to help the OP on that thread.  :)

Yes. Passports don't have PIN numbers attached because they're meant to be used with biometrics instead. The zero-knowledge proof of passport is really a proof of passport possession.

For a corrupt hotel clerk to create ZKPOPs they'd just have to do the same process as ordinary users - scan the photo page or type the BAC details in by hand, then NFC scan the passport chip and process the output. If a customer can see their passport at all times this shouldn't be possible without arousing suspicion. If they take it away then they could do it.

Is this a problem? Well, it's not ideal, but any security system has to make a tradeoff between usability and robustness. In this case the usability would be pretty good if you have an Android NFC phone and a laptop (the SNARKS are too intensive to create on a phone so you'd need a computer to help it), I think it'd not make setting up a node much harder. Certainly it's more complicated and lower throughput than building a botnet.

If you wanted to solve this anyway, you would have to pair it with some third party that verified your face against the passport data. For instance, pick one of N third parties who do a Skype video chat with you, where you hold up a word they give you on a piece of paper, and then it's matched against the passport. Obviously this is more complicated, expensive and involves introducing more ID verification authorities who do the face matching. It may still be easier/cheaper than what Bitcoin exchanges make people do though.


Biometrics data is unreadable because it's encrypted under a key only governments have (edit: to be more precise, the passport challenges the reader which must sign with a country-specific key). The rest of the data is encrypted under a key derived from the photo page because it's just a copy of what you can already see.

AA is irrelevant for this scheme. I mentioned it in the talk only to introduce the "real" solution. AA lets you prove ownership of the passport over the internet by challenging it with a nonce that's signed, but it doesn't provide any way to hide data so it can be anonymous.

Thanks for the answer. I watched the video again and understand a bit better what you're aiming at. I think I get the interaction between elements now: AA prevents cloning, but we don't have that in practice. Also, ZKP wouldn't work with AA because AA checks a signature, but to do that you have to have a pubkey (something like that?)


But on the other hand ZKP + Skype seems to make no sense; I mean, yeah, *some* data might still be hidden but really it does destroy anonymity, in a very visceral way..

Looking at this combination of elements I can't see how it's going to work - assuming (a) AA destroys the possibility of anonymity and/or (b) AA isn't available, as is the case today for most countries(?)

Well, AA is best seen as a feature intended to stop you copying the data from one passport to another. The private key used in AA can't be exported from the chip. I guess it's not popular because the physical anti-cloning features might be good enough to keep passport fraud at acceptable levels, and anyway, duplicating an existing passport must be much less useful than creating an entirely fake one - the digital signatures are enough to tackle that.

With ZKP you don't need AA at all, it just has no role to play.

BTW the slides are here:

https://docs.google.com/file/d/0B4t9VJLm_PWhRkFKa1pQTm54WU0/edit?hl=en&forcehl=1

I do agree that it makes sense that AA is not seen as a priority, because the intended use case is to compare the person with the passport - in that scenario cloning is not quite so big a threat.

But without AA you have no meaningful protection against cloning, so I can't see what defence there is against Sybil if you also want anonymity. (Assuming I was correct about my interpretation of why ZKP+AA doesn't work, was I?)

The attack you're talking about is the bad hotel clerk, right? So AA doesn't achieve anything there because they aren't "cloning" your passport in the sense of making a copy of it, they're just temporarily gaining access to it.

In theory, with AA you could literally attach your passport to your bitcoind full node and have it respond to a challenge on every new connection - this would solve the bad hotel clerk attack because you'd need ongoing access to the passport to run the anti-sybil algorithm. But yuck. Not convenient, not anonymous. We want a one-shot process that derives some data from a single possession, otherwise it's too inconvenient. ZKP does that, but if you only need a single possession, then .....

.... hmm this line of thinking yields a new idea. Perhaps to create this proof you could prove possession of the passport twice, separated in time. Sure, sometimes you give up your passport for a brief period. But probably not for a month at a time. Unfortunately the proving process doesn't have any notion of time. It might be possible to use the block chain, but I'm not sure and would have to think about it more.

Anyway all this is highly theoretical for now. It's not even possible to try implementing until the SCIPR group open source their code.

Oh, for the face match thing - it can be "anonymous" in the sense that all they need to do is match two faces together. They wouldn't necessarily have to know the real name/location/birthday/etc matched with the face. Someone has to check it though. There's no other way to prove you're the "real" owner of the passport vs someone who borrowed it for a bit.

Last time I was in China, my 'building got in trouble.'  As a lodger, I noticed this because I got a note saying they needed my passport for a day and instructing me to drop it off at the lobby.

I did not wish to give up my passport.  As a compromise a van load of cops, and a box of about 100 passports, and me made our way to the police station.  I gave my passport to a lady in the front room of the station.  She copied something off it by hand and handed it back.  The cops too the box of remaining passports into the back room and kindly gave me a lift back to my point of beginning (and didn't even beat me up!)

Thankfully there is no corruption in China and the people are to unsophisticated to do anything with electronic hardware so there was no danger to the passports.

It's a bad idea to let go control of one's passport.  All the travel literature says so.  The trouble is that it is relatively easy for authorities (and others) to make that become the most rational thing to do.  It's also a marvelously stupid idea to give someone the password to one's on-line bank account yet enough people will do it so that Coinbase offers it as a 'service'.


BTW, you know who doesn't fuck with the cops?  The Chinese!  The reaction from my friends when I told them I had to go to the police station was a half a second of wide-eyed terror.  It was similar to the reaction of the round-table participants at the 2013 San Jose conference when it sunk in that the audience question guy was talking about mixing private keys (which I found telling about the methods of blockchain analysis that are likely underway or being contemplated.)

I was thinking that the hotel clerk attack was possible *without* AA. But the rest of your reply makes me see we're basically on the same page now - the only way it works is with repeated challenge-response, which means you need AA or the Skype thing, which is a pretty nasty hack that people probably won't go for.

You could start out by just not doing any face matching and if people do start stealing/borrowing passports to do sybil attacks, see if people are willing to "upgrade" later. It's easy to map out all kinds of possible attacks on any system, but whether they end up occurring in practice or not is often a bit of a crapshoot.

Difficult to argue with that, but on the other hand - weaknesses attract attacks, even ones that look unrealistic.

One alternative point of view is to say that the attack you proposed, basically a "spoof the bitcoin network" attack, is best defended against with existing authentication systems. I know it's not trendy to say, but I would view it like this: if I do a localbitcoins trade, I'm going to go to https://blockchain.info for my confirmations, as well as using a node or electrum wallet on my laptop. These two separate channels make an attack monstrously difficult to mount from outside. If my laptop is compromised fully, then nothing I can do on it will help - so if I'm paranoid (or don't trust my own opsec), I use another channel - probably not my own phone in that case, rather ask the coffeeshop owner to double check blockchain.info.

This approach makes more sense to me.

Great idea Mike, start with it as optional verification and later ensure it becomes compulsory.

I'm trusting you less and less with this. You need to recognise how wrong you are with the idea of using external tokens to verify nodes and admit this.

To mitigate an ad-hoc Sybil attack, isn't it sufficient to be able for a node to discover the following circumstances:

• peers which have been seen previously (pre-Sybil attack) are either no longer available or imposters,
• all available peers which act normal are previously unseen peers.

If a Sybil attack is staged using a malicious wifi hotspot in a public place, it can essentially be detected by looking for these conditions.

Right?

Nodes don't have any way to authenticate themselves currently so you can't do that.

If you could do that, the question is what do you do next? Can you tell the difference between "the nodes I was previously using have simply gone offline because I was away for a month" vs "I am being attacked"?

For this a simple challenge-response can be used, and setting up a secure channel using a shared secret exchanged during the first time they discovered each other.


No, but in your own example, you mention:

• walking into a coffee shop and connecting through a random, never seen before hotspot,
• not wanting to wait for confirmations of a transaction.

If under these circumstances, none of the nodes I have seen before appear on-line, then that would be more than a little suspicious, and I can either try to use a different channel to connect to the internet, or simply wait for any transaction to confirm, or both.

In general, it is suspicious if all nodes on the network seem new from one moment to the next.

This would sufficiently solve a Sybil attack, which is quite difficult to execute already, and, by your own words, has never been performed before.

This Proof of Passport just seems a solution in search of a problem. And the solution does not even work.

Now we've had a chat about it, my view of this is starting to crystallize. The problem for me is not so much that the trust root being proposed is governmental (although I don't like it). That is not so far away from using a corporation as a trust root. The problem is fitness for purpose. These passport systems were designed to match a physically present human being to an entry in an ID database. They don't provide for a uniqueness guarantee combined with anonymity, even using ZKP (from our conversation thus far).

Using passports in this way is hacking in the purest sense. These approaches *can* work, for a while; for example using Amazon as trust root in an oracle as we did in the ssllog project, actually does work - but it may break at any time in the future, precisely because our intended functionality is of no interest to Amazon, and that's the same problem you have with passports. And unlike the Amazon oracle, I don't think this passport system even works right now (I mean assuming the snark/scip/zkp or whatever stuff works), because of the mismatch I mention above.

Did you watch my talk? There are two types of sybil attack I discuss. One is the wifi attack, for which I propose Tor.

The other is for flooding the network with bogus peers in general. For that I propose proof of sacrifice, and proof of passport.

What you are talking about is relevant for the first case only, for which using Tor is sufficient.

I like tackling both problems with one stone.  Here's a solution that, yes, will require an extension to our current P2P protocol, but kills many birds which you only begin to address here:

1> When nodes discover each other for the first time, they share public keys with each other, which becomes a form "node ID".

2> A node will collect the IDs of the nodes it talks to, along with certain meta data, such as average latency over the past 24 hours, 30 days, etc,...

3> When a wallet talks to nodes, it collects their public keys.  When it transactions via them, it notes, it to.  So, a node confirming a transaction can be proven over time to have participated in the Bitcoin network.  We can decide what activities help to define honest participation, effectively building reputations for nodes.   

4> A node can periodically ask its peers to share the meta data they have on it, which those nodes sign. 

5> When your wallet to a node it's not sure it can trust, you can ask it for proof of network interaction.  It then signs a copy of the signed testaments of other nodes it obtained in #4.

6> Your wallet can compare the node keys in #5 against those previously collected via #3.  Based on this, it can create a "trust score" combining these factors. 

To be sure, this "trust score" isn't 100% guaranteed.  It only says that here are reasons to believe that the node you are thinking about trusting has given certain evidence of its reputation via peers you have used in the past.  In the end, the human with the wallet still has to decide if this "score" meets their threshold before completing their transaction.  But, like 6 confirmations, we can come up with a scoring system that, in the end, increases the expense of creating a fake wifi and bogus peers. 

This system can be extended using a "bad transaction" blockchain, because if you complete the transaction with a descent score, and it turns out to be bad, you now have proof that the node owning that key lied.  Because it took effort and time for that "node ID" to build a reputation, that reputation is thrown away.  Node reputations become the cost in this model, which take time, at a minimum, to earn. 

On top of that, we can include other meta data in the bad transaction chain, such as IP address.  Over time, we can use it to analyze these threats better and create better counter measures. 
         
Let's step out of our current problems and look at the possibilities.  We're creating a chain, not for currency transactions, but for network health intelligence.  Other types of network health indicators can go in there.  This can help the network learn how to improve, to increase resilience, to be more healthy and protected from various types of threats, like the 51% attack. 

Yes I had watched it, but now watched it again. What you said in your talk was:

1. A Sybil attack can be carried out by tricking a node into thinking it is connected to the real bitcoin network when in fact it is not, by basically spoofing the bitcoin network over a controlled internet link. Tor can mitigate this Sybil attack, because it is impossible to spoof the Tor network, and the node has a way to discover that it is not connected to the real bitcoin network.

2. However, Tor introduces another problem since it hides IP addresses. It is not possible to verify that nodes seen through the Tor network aren't actually all coming from a single computer. This gives rise to another Sybil attack, where it is possible for a single computer to flood the network with nodes.

For 1, my proposed solution based on building trust would solve it, but so would using Tor.
For 2, we need proof of sacrifice or proof of passport, which is intended to prevent a single person or group from flooding the network with nodes.

Agree so far?

Now, the root of the problem seems to be the fact that one person or group is able to control a large number of nodes, enough to trick a peer node into believing it is connecting with the real bitcoin network when it is actually not. To mitigate this, a node must somehow be able to prove itself in a way that can not be easily replicated. Your solution proposes to use a proof of passport - a document with unique, verifiable properties, which you presume are hard to obtain. That would make it impossible for an attacker to flood the network with nodes, because each node requires a proof of passport.

Agree so far as well?

Now my problems with this:

1. It will not be difficult for a determined attacker to obtain many proofs of passports. As soon as proofs of passports obtain value, hackers will have them for sale in quantities, making the proof of passport instantly worthless.
2. It raises a barrier of entry for someone to participate in the network with a full node. A minority of the people own a passport. Only a subset of them will agree to provide a proof of passport for the privilege of running a full node.
3. What happens if someone else obtains my proof of passport and also runs "my" node? How does a network decide which node is the "good" one, and which one is the "bad" one?
4. I'm concerned about the privacy and security implications. A passport is gets tied to a node. Can't oversee this fully, though, I admit.
5. There might be better alternatives to solve this problem.
6. Despite you tinkering with the idea for over half a year, it's only now that an in-depth, serious, critical discussion is starting. The discussion should have been started by you six months ago. I'd expect a lead developer to more actively engage with the community for ideas that you can suspect to be controversial.

I think 1 is the elephant in the room, has been mentioned several times by multiple people, but unfortunately has so far not been addressed by you I think.

Quoting myself:


How about asking all peers to simultaneously provide a small proof of work before trusting them? If the peers are all the same node, this will be suspiciously slow. Also, previously seen nodes may have previously known speeds. If a node is slower than usual, then this is also suspicious.

Could that work?

The limitation with that is you're now asking the nodes to become CPU intensive.  What's their incentive? 

Because this is a network problem, solving it at the network level permits P2P itself to become more robust.  This benefits bitcoin, but also other usages of P2P. 

While proof of work apparently works when you are talking about generating currency with value out of thin air (mining), it doesn't transcend well to other tasks.  With networking, efficiency and speed is a goal, and the primary value is in the sum of the parts rather than individual pieces.

Of course, I love that you are looking for an alternative to Mike's passport approach.  :)

Well, to support the bitcoin network of course. Isn't that the whole point of running a full node?

And it should not have to be that computationally intensive, because it only required once when first seen, and once when doing a transaction. There are no doubt better ways than I can come up with to implement it, but imagine the following simple and probably naive implementation:

Before doing a transaction, a set of nodes can be asked to repeatedly scrypt the same a string for one second, and provide the outcome, with which a lower bound for each of their speeds can be established. If this is not radically lower from the speeds that were found when the node was first seen, then the node is considered to be safe.

The fastests nodes can be considered the safest, because they will be the hardest to spoof.

Or each time a block is broadcast, it picks up 'breadcrumbs' of transmission times along its journey from A --> B. This generates a local network routing map. These breadcrumbs are somehow secured with a work function taking a certain amount of real time (perhaps hashes of time T=0 and time T=0+100msec) so you can see whether it's been artificially hindered or sped along its journey along one route. The breadcrumbs can be discarded after 'proof-of-connectivity' is established so as not to clog the block chain.

Thinking further, are there such things as hardware naive timing functions, perhaps a simple counter, say 'count to X' with the start time and end times signed. This would provide a hard definition of the expected performance of a node the next time it's questioned - if suddenly the timer takes longer, it's possibly compromised. You'd of course have to ensure that no 'sleeper cells' were installed along the way, waiting to suddenly begin relaying forged work.

The problem with proof of passport is that there are many people who have dual citizenship or even three or more citizenships. Since many countries in the world allow for dual citizenship these people can legitimately have several passports from multiple nation states. Furthermore dual citizens tend to breed dual citizens since many nation states recognize citizenship passed on from parent to child. This creates the possibility for a small family to have access to eight of more passports all legitimately obtained, more than enough to set up this kind of fake network.

By the way Canada a nation with a large number of immigrants that allows for dual citizenship is a perfect location for this.

Edit: Here is an example of the dual/triple citizenship attack on the proof of passport idea: https://bitcointalk.org/index.php?topic=433122.msg4765658#msg4765658 (https://bitcointalk.org/index.php?topic=433122.msg4765658#msg4765658)

I mentioned in the talk that the difference that's interesting is "a few" vs "thousands" rather than one vs a few. If you bring up 3 nodes, that's not a bad thing! Heck, bring up 10! As long as a single wallet only uses one of your nodes per session, that's no big deal.

So yes I am aware (and already was aware) that some people have multiple passports, it's not like I never heard of dual citizenship.

The way the zero-knowledge proofs work is that you can choose what to include in the boiled down hashed data. For instance you could just include name and birthday. It'd mean a wallet might avoid connecting to two nodes run by two legitimately unrelated people if they happened to have the same name and be born on the same day, but it'd also mean they'd avoid nodes run by one guy with three passports. But the scale of these attacks isn't very interesting.

As to why I talked about this now instead of after six months, well, er, I don't give talks very often? At any given time I've got a billion ideas floating around in my head and frankly, I'm unlikely to post any of them here given this forums track record:   people flame, they hate, they make threads with titles like "How do we stop Mike Hearn" and often they haven't even actually read or understood what I really said. If you're surprised that I might not rush to post every idea I come up with here .... don't be.