We can create real passports, that are actually more valid than a government produced effort. I don't know why anyone would trust government passports anyway, it proves that either it's real, or that you had the money and means to get a fake. Not really much use as an ID in the 21st century anyway.
Go for it! If you think you can verify and issue identities that are harder/more expensive to forge than passports, and which the majority of people are eligible for, then the "Carlton Banks Pass" would work just as well. There's no particular reason it has to be a government issued ID, it just happens that governments put a lot of effort into issuing these things at scale, there are international standards for them, they can be read using Android phones, and lots of people already have gone through the process to obtain one. So in that sense it's a convenient existing infrastructure that can be reused. That's an almost perfect example of argument from ignorance, ergo: I can't think how to make something like passports, therefore it can't be done. You've still not addressed the concerns over requiring external tokens. We expect better from someone so deeply involved in bitcoin development. |
|
|
|
Hi all, There have been some heated discussions on here since Mike Hearn's 'proof of passport' talk for identifying valid nodes to prevent man-in-the-middle attacks (here: http://www.iamsatoshi.com/coinscrum-networking-evening-circle-london/). I think that any solution that would require a token external to the bitcoin network itself, such as passports or ID cards, are inherently counter to the trustless, decentralised nature of bitcoin, as well as being potentially open to manipulation by unsavoury characters or forces either now or later. The problem as it stands was stated quite well by erik777: The bottom line is if you're trying to detect the integrity of a node you're talking to, you are asking peers that have talked to that node in the past that you've talked to in better contexts. Each node can track latency, uptime, etc, on all the nodes they talk to. They don't have to share details, just how normal it is.
To be sure, you can't 100% trust any node. That's not the goal. You're just trying to make it more difficult for someone to create a fake bitcoin network on a wifi spot they are hosting. This can make it virtually impossible to pop up a bunch of new nodes with no history on the bitcoin network, or to bring them up and down. Does it rule out every type of node fraud? No, but it makes it much harder. You'd have to create a history on the network with your nodes. And, as soon as your nodes are identified as bad, that history would become moot, requiring a new history.
You are creating higher credibility for nodes with a HISTORY of uptime, consistent latency with its peers, and presence on the blockchain over those that are new, credibility you'd primarily use when on an untrusted local network and you need transaction confirmation quickly, the scenario Mike is trying to address with passports.
This is not the same as real world trust networks. This is based purely on network data, with the network reinforcing itself, increasing its own integrity dynamically. This is still conducive to a trustless network so long as you don't make it part of your core, but an add-on to offset those times when you can't otherwise trust the network and nodes you are currently talking to without a historical linkage.
My personal feeling is that a 'proof-of-connectivity' relying on data transmission rates and time-stamping might be a way forward, and I'm currently looking for academic papers that could back this idea up in purely mathematical/objective terms. 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 trustless 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). So, we all know that: 1. Time moves in one direction 2. Networks have non-zero latencies between nodes 3. Geographic location can correlate with local network latency/routing 4. Time stamping CAN be highly accurate with modern technology I believe a combination of these factors would allow more objective identification of nodes, using inherent properties of the network itself to provide zero-trust identification. The results could be hashed and encoded into blocks delivered by a particular node, thereby putting a form of the map into the blockchain. I am NOT advocating white/black/brown-listing in any fashion, merely local trustworthiness built upon a history of functionality within the greater network. All thoughts welcome. Previous discussion here: ( https://bitcointalk.org/index.php?topic=429264.msg4753847). |
|
|
|
Also, I threw in the concept of identifying a bad node requiring the operator to create a new node with no history. That sounds like blacklisting, but here's the difference, because like most here, I'm completely against PEOPLE blacklisting nodes.
Node X is bad, but has an untarnished history on the Bitcoin network. Node X forwards you recent attestation from its peers, peers you've built some credibility with by using them in a trusted setting, such as at home when you received Bitcoins.
Node X then lies to you about the blockchain because Node X has considered you its mark. You rely on this and hand over your fiat currency in the cafe.
If Node X signed its lie with the same public key that its peer nodes used to attest to the facts they knew about it, you can now take this signed lie and put it on the "liar liar node's on fire" chain. You've now provided proof that node X lied to you that the Bitcoin network can see.
Yes, it won't get your fiat currency back. You'll need muscle or persuasion for that. But, it will help to erase the historical integrity that node X established on the Bitcoin network. It isn't blacklisting, because you only proved that X lied, which you could not forge without X's private key. No human can blacklist anyone. But, we can prove when someone signs a document that contains a lie about the blockchain.
Sounds very good, and in keeping with the 'maths is more objective than humans' ideology of bitcoin network. I'm going to open up a new thread about this as recommended by coinrevo. It'll be titled something like 'Establishing node trustworthiness without external tokens'. |
|
|
|
After thinking about it more, the passport idea does seem a bit lazy (though still not malicious as many have accused). The risk of all of the hashes being bruteforced is a pretty large downside since those who would need to provide that extra identification most would be running over Tor and likely not keen on taking any chance of having their identity revealed. 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). This is an interesting idea but I doubt it's so simple in an actual network. Do you know of any academic papers or what not that actually promote this idea? It would also be kind of silly to blacklist a reliable and honest node just because it moved. I like the concept because it is using current trustless info to build common sense intelligence, and is quantifiable. I don't think this implies blacklisting the node that moved. It just implies a lower trust level in the near term until evidence showed it moved. Lower trust simply means it wouldn't be trusted as the sole source of a confirmation when on an untrusted network, the open wifi example Mike gave, but can participate as a normal node otherwise. The bottom line, while the devil is in the details of ANY proposal, I prefer one that builds on the data in our trustless network to create node signatures and reputations that can be used when relying on confirmations on an untrusted local network, partially attested with signatures from nodes. I think it's fair to presume that if someone is using wifi to fake a network, they still won't have the private keys of the reputable nodes, right? If they do, then we have a much bigger problem. Sorry for the massive quote but I'm on my phone... Thanks for the reply - you're absolutely right that I'm currently lacking details required for implementation. I AM currently looking for academic papers that could back this idea up in purely mathematical/objective terms. With all this talk of Mike Hearn's proposal for external tokens to verify nodes, I just wanted to hypothesise potential alternatives based on the network we already have. We all know that: 1. Time moves in one direction 2. Networks have non-zero latencies between nodes 3. Geographic location can correlate with local network latency/routing 4. Time stamping CAN be highly accurate with modern technology I believe a combination of these factors would allow more objective identification of nodes, using inherent properties of the network itself to provide zero-trust identification. I am NOT advocating white/black/brown-listing in any fashion, merely local trustworthiness built upon a history of functionality within the greater network. |
|
|
|
|
Is someone starting to smell a scam?
'I run a porn site that I can't show you because porn is rare and special on the internet'
'I won't list on a public exchange, thereby increasing trust and attracting more investment'
'Yes I've definitely paid out these dividends/am worth this much'
|
|
|
|
|
Jimmothy, you're dead on the money.
Any company that thinks it's worth 1/12th the total money supply of an economy is either lying or delusional.
|
|
|
|
|
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.
|
|
|
|
Here is a scenario. In a small country with a brutal dictator inflation is rampant. People switch to cryptocurrencies to avoid confiscation of their wealth. As they don't know any better they use government ID's in conjunction with the system. Some day the mechanism is compromised and the government obtains all records of people using bitcoin in the country. the people are arrested and thrown into jail.
better to think more about what the consequences of actions are. would bitcoin developers compromise security in poor nations to get some added benefits in rich nations? the world is a pretty big place.
 Bro, no one cares about your role playing game scenarios. We are not playing Shadowrun here, we are discussing technical solutions for a security issue in the Bitcoin P2P network. I have never disliked someone on a public forum quite so much before as you. Genuinely, your antagonistic and arrogant platitudes just get my back up. You continually belittle bitcoin as 'just a p2p network', totally ignoring the value already held in bitcoins and its potential future. Why don't you just fuck off? |
|
|
|
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?
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? |
|
|
|
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. CNNForbesFor 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. 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. |
|
|
|
|
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'.
|
|
|
|
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 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. 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. |
|
|
|
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.
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. 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. |
|
|
|
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. So we should trust keys issued by waxwing instead?  There are large organised crime gangs that stand to make millions by subverting the passport infrastructure (think about gangs getting illegal immigrants through the border). The stakes are already very high, so at least the incentives to get it right are there. It wouldn't surprise me if some (smaller) governments do screw it up, but if so, I've never heard of it. 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!!! 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. |
|
|
|
Take the 3 million raw I/Q samples per second of background radio and send the data through about 10000 XORed SHA hashes to get 512 bits a second. Random.
This is digital random. It is analog random that is proposed in this topic; its work is based on such phenomena as nuclear resonance serving as a source of quantum entropy. Please correct me if I was mistaken. And why is this an advantage? (i.e. why would I invest in this) - I want Altoidnerd to explain his 'value proposition' - what makes his solution unique and valuable in the current market. |
|
|
|
No, not exactly. The passport verification doesn't submit identity. What is optional is the choice to add some sort of extra data to your node to allow others to make some determination about it, which can be helpful to them. This can be done by regular users in two suggested ways: passport verification, and proof of sacrifice which incurs a small cost. Additionally, high profile non-anonymous nodes (e.g. MgGox) can also be used in helping clients try to identify the authentic network. Using these three things together appears to me to provide great benefit with no apparent downside. That's the substance of my argument.
I like the concepts of 'proof of burn' and using non-anonymous nodes for route mapping far more than using a centrally-issued token to tag a node. One concept I've been toying with (but don't know how to implement) would be a 'proof-of-connectivity' relying on timestamps and the times to relay blocks locally in order to generate a zero-trust map of inter-node connections…might need some additions to the block header to record hashed chains of local timestamps vs. the median network timestamp to build up the record of all the nodes through which a block has passed. |
|
|
|
In this case the fact that the remote client (wallet) is being persuaded of is that you know a valid e-passport that hashes to a particular value. It's anonymous because you can't reverse a hash. You can convince the wallet of this without actually revealing your passport data.
Which hashing algorithm would you choose? Because even now people have questions about this particular aspect of security. And the rest of your answer still does nothing to address concerns over 'region locking' of bitcoin nodes - what if we just decided that today, nobody from Zimbabwe can access the blockchain? |
|
|
|
This sounds like a lot of chemical jibberjabber for something that can be done with webcam noise or lava lamps. One solution I would have is to take a software defined radio such as http://spectrum.ieee.org/geek-life/hands-on/a-40-softwaredefined-radioTake the 3 million raw I/Q samples per second of background radio and send the data through about 10000 XORed SHA hashes to get 512 bits a second. Random. Good point - Altoidnerd, what does your solution offer that these don't? |
|
|
|
|
I'm guessing you're at a university or other institution if you have access to a few US$100,000s of lab equipment. I would strongly advise you to look for local business plan competitions, or speak with someone at the business school about building a team to take this forwards.
I suspect if you're right, you have the potential to affect a large number of fields beyond bitcoin.
|
|
|
|
Let's recap the problem: we want to identify the "good guys" in our network but without centralized authority.
It's even simpler than that, we only want to prevent anyone from spamming us with "guys", be they good or bad. The basic idea is, someone who pretends to be a lot of random guys is probably up to no good. It's only a hand wave to say hey I'm okay if you want to listen to me.
Again, it's simpler than that, it's just a hand wave saying "hey, I do have (exclusive) access to a random, unique piece of paper". It doesn't qualify you as being okay. I think you're almost on to something. Could you possibly expand upon what you're thinking, and any solutions? |
|
|
|
|
Show Posts
