Topic: Establishing the Trustworthiness of Nodes without External Tokens (eg Passports) - page 2. (Read 3622 times)

Nope. A "confirmation" is a valid block with the transaction included, and a valid block includes a proof of work. The proof of work is far too valuable to waste trying to double spend in a bar.

One worry is the bar thinks its getting paid because it's seeing false confirmations, when in reality it's giving away drinks for free because the transactions are never getting relayed to the rest of the network.

Its not how bitcoin works, but its an interesting concept. Instead of having the whole world verify blocks, one could somehow use nodes in some proximity. One could call it local web of trust.

You need to read more about how bitcoin works. First of all, the bar doesn't send blocks anywhere since it doesn't mine. It doesn't even send transactions, it just listens for incoming transactions and incoming blocks. Secondly, transactions are signed before they're broadcast to the network. Once they have been signed, they can't be tampered with. So your MITM can't edit any transactions. What he can do is be selective about which transactions he forwards where. If he were to collude with the customers, he could help facilitate double-spending attacks against the bar, but as mentioned previously any such attack could quickly be detected.

The bar thinks the man with the suitcase in the corner is actually a node. The bar is relaying blocks to the rest of the network through this supposed node. The blocks either get edited or just not relayed to the rest of the network. The man with the suitcase pretends to the bar that the block has been confirmed correctly. The man with the suitcase walks out with BTC.

How? It can't get the bar's private keys, and it can't change the bar's receiving addresses. So how is it supposed to get hold of those coins?

What do you mean? The MITM spoofing the node gets to run away with all of the BTC that the pub took that evening.

So if nobody can steal anything, what's the problem?

That's not the worry. A man-in-the-middle attack (MITM) means that what the bar thinks is a valid node to the rest of the bitcoin network is actually the perpetrator.

That's the scenario we're talking about here - validating the pathway between user <--> node.

I want the validation to remain trustless and to not require any external validation e.g. "I say my node is valid and here's my driver's license to prove it." - validation should be like the rest of bitcoin: trustless and distributed, built upon a cryptographically signed 'proof-of-x' function.

What problem? Nobody can steal a customer's money that way. The bar won't give the customer an address that the bar doesn't control, and the customer won't sign a transaction to any other address than the one he receives from the bar. Are you worried that customers will double spend against the bar? If so, it'll quickly be discovered by the bar.

NanoAkron, I think its valuable to think about these concepts, but unlikely they can be integrated with bitcoin. same with true identity which was kind of the goal I suppose with the passport mapping idea.

Proof of work is really a very clever workaround to achieve a certain goal, based on the fact that cycles can be moved around the globe arbitrarily. If one removes restrictions of TCP/IP one can redesign the PoW scheme. After all it also makes a lot of sense to have local money supply and money functions.

cjdns is an alternative to TCP/IP and uses cryptographic functions right at the core (an IP address is not a number assigned by an authority, but a node has a keypair). unlikely TOR the nodes' location are traceable. so you have some sort of identity and trust system build into the network, in a local sense.

Ah, yeah, my mistake, I misread that.


It's just simple numbers - there's ~3,000 Tor nodes out there, and actually quite a bit less than that in terms of bandwidth product. If you don't create something honest people actually use, on a wide scale, what you've created is something that dishonest people use, on a wider scale. Remember that passports are held by large numbers of people, the GCHQ isn't going to have a hard time finding government employee with all kinds of passports, Russian, Chinese etc. even without faking them. (my former ~50 person company had individuals with those passports, and Iran, India and Pakistan among others) And if they do decide to hack them you've got a handy anonymous ZK proof scheme to cover up the fact you've done that.

Thank you for your reply. I'm trying to solve one specific problem I have in mind and see whether that could generalise to addressing some other issues in BTC at present.

Problem: Walk into a bar, pay for a drink, BTC vanishes into thin air because the node was spoofed or you got MITMd.
Problem 2: 51% attacks through mining pools

My proposed solution of encoding the 'linkage' between nodes could simultaneously address both of these.

Scenario 1:

If the node you see in a pub actually has no verifiable linkage history for its expected geographic location, it may be a spoofed node.

Of course, the bar could have just opened. But if they're running a true node, they'd be processing BTC blocks and building their reputation with other nodes. This could perhaps be in the form of an adjustment of new transaction fees (low for new nodes, higher for older ones) or maybe a CPU intensive relay delaying function so that like old fashioned password lockouts it would take a restrictively long time to continually spoof a node. Just thoughts at present, but still not requiring any verification tokens that are external to the network.

Scenario 2:

A mining pool has 51% block discovery rate. Well, they're probably operating through a handful of dedicated nodes. What if connectivity was reflected in an additional 'difficulty' metric added to the existing network difficulty (the 2016 block, 10-min difficulty).

I.e. more connected nodes relaying a lot of traffic between themselves have to work that little bit harder to process blocks relayed from each other, but less hard to crunch blocks from more distant nodes - this would encourage the network to preferentially source blocks from more distant nodes over more connected ones. This prevents a 51% attack by preventing chains of blocks being sequentially delivered from the same nodes, ensuring a good mix of blocks in the overall chain.

So, could 'local difficulty' and 'local fee' adjustments depending on node connectivity ('proof-of-connectivity') address both of these issues?

I think you're misreading what was said.

Tor breaks if you pick three relays you think are not collaborating against you, but they actually are. Obviously if the Tor network is flooded with nodes that look superficially unrelated but are all run by an adversay, the chances of being deanonymized go up a lot.

I did not say you can't tell Tor nodes apart, so I'm not "propagating falsehoods". I said you can't know if they're really run by independent entities or by the same guy/people.


Anyone who wants to run Tor nodes can get a passport or use their existing one, it's not like there's a "no Tor" rule enforced by any countries passport office.

GCHQ might well be able to fake a large number of British passports, or heck, just use those of their employees. Perhaps they've even been able to hack a foreign country or two's passport agencies - who knows. But you can play geopolitics by having the ZKPOP reveal the issuing country and then picking relays run by citizens of countries that hate each other. That raises the stakes a lot - if GCHQ is forging a foreign countries passports that can, if discovered, turn into a major diplomatic disaster that isn't worth it.

In the current world all they have to do is rent a lot of servers around the world via front companies, hardly a big deal, and then run modified Tor nodes that log circuit activity. It can't get any easier than that.

I believe the problem is that most concepts of traditional cryptography and computer security don't really apply. This is as much as about economics as anything else. Some of the real issues are just always out of scope in these discussions. One can't begin talking about them without having a different framework. One dimension from many of the current discussions missing is the political dimension, i.e. the effects on organization. This is not just about contracts, as contracts are rooted in legal system and government. Anyway, I don't think a purely technical view is really going to help very much to understand this. One can see this with the current designs of the payment protocols.

OP raises some very interesting points about the concept of geographic location. In a local context many of the concepts changes. As an example: in the context of traffic I trust that other actors will act a certain way. But I don't need to trust all actors, just actors around me at a specific moment in time. Most transactions take place in a geographic context.

If one thinks about these things in conjunction with meshnets I think one can come up with some very interesting thought experiments and future directions. I doubt that the next paradigm shift will be like the last, and at some point it might turn out that extending bitcoin might not be possible in the way it was thought. At least that's my conclusion from investigating all the "advanced" applications. There is the meme the bitcoin is like TCP/IP. I believe the relation of cryptocurrencies to protocols is quite complex and very different.

Mike is propagating falsehoods. Here's a list of all Tor nodes: http://torstatus.blutmagie.de/ The organizations running many of those nodes make a point of advertising who they are and the fingerprints of the exit nodes they run: https://www.torservers.net/exits.html That also applies to relay nodes: http://www.enn.lu/status/relay

Tor is a technology, but it itself is just a tool; the reason why Tor can be used relatively safely is actually because of human social protections, not just cryptography. Infiltrating Tor is harder than it looks because you have to infiltrate large numbers of real-world organizations comprised of actual people - just the kind of thing that leads to rather undesirable leaks. It's also rather similar to how I've argued for some time now that the Electrum SPV clients are probably more secure and private because they rely on a small number of Electrum servers run by relatively accountable people rather than a large number of completely Bitcoin nodes run by parties unknown.

It's easy to know if some Tor nodes are related and who runs them: there's a large number of high-bandwidth donation-based nodes run by various charitable organizations, e.g. torservers.net, and those nodes are well known. Tor does not fundamentally break by having who runs what nodes be publicly known - that's exactly how Tor already works.

The other interesting thing is that because tor is a semi-centralized system proof-of-bandwidth and proof-of-low-latency is practical - the central organization is trusted and can make the measurements - and that makes for a good lower-bounds on the financial resources expended to run those Tor nodes and the geographical decentralization of them. Basically it's a better version of proof-of-sacrifice, better because the "sacrifice" is inherently the thing you're suppose to be providing.

You're criticisms do apply to the I2P network though, a common criticism of it verses Tor.

Meanwhile if the GCHQ is your adversary, why are you making their job easier by giving them a huge advantage - they have access to tens of thousands of real and faked passports - that the honest defenders don't have?

After giving it some more thought, I am starting to think that this can't be solved.

The problem with Tor is that you can't tell nodes apart. This, I believe, is a fundamental property of Tor as it intends to hide any network information. There is simply no way of knowing whether two or more nodes are on the same computer and controlled by a single person or group.

The only inherent property of a node that I can think of which can be verified securely is a lower bound for its computational speed. This can't be forged.

But nothing stops someone who wants to spoof the network with nodes from creating a huge number of nodes each pretending to have low computational power. At best, it would be suspicious.

I think when you think through the problem, you'll end up with a verification which is already in place: proof provided by the majority of computational power in the bitcoin network.

There's simply no replacement for that.

Ugh...

I wouldn't dare think of you as in any way lazy, and it's a shame that ideas can't be tossed around freely in Bitcoinland without witch-hunts ensuing.

I'm glad my little talk is prompting people to talk about sybil attacks, but this conversation is confusing because you're all mixing up the two different types of attack I discussed (with two different types of solution)

1) MITM on bad wifi connections. Proof of propagation/connecting directly to miners/etc is in the same general area as connecting to randomly chosen peers through a trusted proxy. Most users don't have trusted proxies, but we can pick some Tor exits at random and correlate their answers to approximate this, which is what I proposed in the talk (and actually we're working on this for bitcoinj already).

Don't get me wrong - I like proof of propagation, if the bandwidth and latency requirements work out (I'd like to see some more detailed maths checking this). But it's not a whole lot different for solving case 1 than just using Tor.

2) Flooding networks with peers that look unrelated but actually aren't. Tor has the same problem, so I'm interested in solutions that generalise to all P2P networks. For these proofs of propagation etc are irrelevant. For Bitcoin it might be possible in every case to come up with fancy tricks based on proof of work, though remember someone has to actually write the code for all of these ideas! But I don't see how to avoid the issue with Tor. There just isn't any reasonable way that the Tor directory operators can know if nodes are related today, and if they are, Tor fundamentally breaks. Given that GCHQ has been tasked with breaking Tor (they're thinking of the children you see), advanced sybil attacks on it seem more likely than not in the near future.

Anyway, like I said, I love all the ideas flying about. But ... I'd appreciate it if in future people don't take material that was written to be interesting for a short presentation and make stupid assumptions, like if I talk about one or two solutions that must automatically mean I didn't think about any other solutions, or am a "lazy thinker". It was a 15 minute meetup talk, not a university lecture series.