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

It's not the patron doing a double spend that's the worry, it's the guy sat in a corner with a briefcase pretending to be the node who mops up the evening's takings and slips away in silence. He's the 'node' we need to verify.

Thanks Peter, I forgot about the proof-of-propagation one.  I remember it sounding pretty slick.  Regarding miners publishing network addresses, Mike raised the issue of load balancing with something similar.  I guess that'd especially be a problem with most miners not even running full nodes.

I think you're extending it really, and you're probably not extending it in a way that really works. A good question to ask yourself is "How could I attack this with a bunch of fake proofs?"


Nah, a pub is a pretty good example of why zero-conf doesn't matter all that much: If someone rips you off, you've got a pretty good chance of finding out in a few minutes. Ask the bartender which patron paid for it and have your bouncer go have a chat with them. Even with the busiest clubs this works pretty well - they've got security cameras everywhere to track down that person.

Agree with you about your second point. Any thoughts on a 'proof-of-connectivity' for nodes, or am I just re-thinking the 'proof-of-propagation' issue?

As to your first point - some pubs take thousands in alcohol sales in a single night. If you could MITM them, laptop in a bag hidden in the middle of the busy room, they'd be in big trouble. This is where I feel zero-conf guarantees will be needed.

Something that's been proposed a number of times is that miners include node addresses of some kind in the blocks they mine. For instance a IP adddress + pubkey or Tor onion address. (which includes its own pubkey) With that mechanism being surrounded by malicious peers does no real harm - either those peers fail to relay block headers to you, resulting in you knowing you are disconnected, or they do, which lets you easily connect to a majority of hashing power reliably. In either case the replace-by-fee logic works fine. With regard to fees that also lets you make sure your unconfirmed transactions have gotten to hashing power reliably, so you know that if a miner is willing to accept your tx at the given fee, they had a chance of doing so. Similarly proof-of-propagation can be used for that information.

Where (U)TXO set commitments matters is to make sure peers aren't hiding any relevant transactions from you, and even without them there are lots of way to get the same effect like random sampling, and maybe most importantly, keeping your queries anonymous with Tor, VPN's, and good blockchain query privacy measures.


You can also use fidelity-bond's to guarantee to the recipient that you won't double-spend a transaction - a very easily proven thing.  Off-chain transaction systems in general solve this problem too.

It's also worth remembering that it's actually pretty rare to need solid zero-conf transaction guarantees anyway - in almost all cases either you're not actually shipping some product immediately upon payment receipt, (shipping a product) canceling it after the fact is easy, (subscriptions) you know your customer anyway and can trust them.

Resorting to reliance on centralized, government controlled, systems as step #1 is just lazy thinking, and in this case encourages people to use Bitcoin in ways that are fundamentally unsafe without central authority.

As I understand it, the scenario we're dealing with here is: SPV + 0-conf tx + malicious sender + all peers controlled by sender.  People are focusing on ways to make the latter difficult via Tor + anti-sybil measures, but you appear to be suggesting that this isn't actually necessary.

The tools I'm aware of to perhaps help here are:

1) UTXO set commitments enable SPV nodes to fully verify the received tx, which is nice, but of course the tx won't actually reach the miners before being double spent, since the SPV node is surrounded by the sender's nodes.
2) Replace-by-fee can create an incentive for the sender not to double spend by enabling you to, before any confirmations have occurred, spend the full value to fees, where the sender has included a bit extra which would otherwise have been sent back to him.  But this also doesn't actually help if the sender has you surrounded in the network, since you'd be relying on him to broadcast the replacement in time.

Are there some other tools I'm missing?  What lines are you thinking along here?

Edit: This https://bitcointalksearch.org/topic/off-chain-anonymous-transactions-by-secure-transfer-of-private-keys-321085 is maybe another way I know of.

Thanks. As per the wiki, "SPV does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity."

Personally, I'm not too happy with the idea of 'trusted nodes', so let's focus on the 'high difficulty' side instead.

In other words, let's make it very difficult for a node to be spoofed. Mike Hearn's suggestion is to verify nodes through an externally issued trusted token.

I want instead to make it nearly impossible for nodes to pretend to be truly connected when they're actually not. Hence the idea of a 'proof-of-connectivity', relying on a p2p methodology and fixed physical principles (timestamping and non-zero network latency) and forming part of the core of node functionality.

What do you think?

You're asking the wrong question really. The thing to do isn't to try to better establishing trustworthiness, it's to use Bitcoin in ways where you don't need your peers to be trustworthy. After all, the whole point of Bitcoin itself is to create a currency system where trust isn't required, and Bitcoin is quite successful at that. Don't screw that up by adding "trust" all over again.

So here's your new questions: "Why would a SPV client need to trust a peer?" and for each of those reasons "How can we improve our security and remove the need for that trust?"

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:



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://bitcointalksearch.org/topic/m.4753847).