Save the investors…like the guy you're now refusing to pay back? Brilliant.

Don't worry…I'm outta here.

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.

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

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.

He won't tell you. Porn sites are too special on the internet and need protection.

And now you're ignored.

I like this idea, but the passthrough should be signed by the exchange or the company behind the stock because that's the only way to guarantee its trustworthiness.

What a stupid thing to say. We're here to talk like adults. If you want to talk like a child, go associate with other children.

Wow. Ok, for my education, can you name any other 'scams' like this one? And not bitcoin ones, real world ones like NeoBee.

Nobody is stopping you from buying later at the same price (if it stays that way - again, no guarantees here).

What we are trying to say is that this would be such a monumental scam that there would be real-world consequences for Danny and the others.

Yes, businesses fail in the real world. But a business like NeoBee needs to come along sometime for Bitcoin, and Cyprus + the Euro is the perfect storm to allow it to happen here and now. That's why I've invested.

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 take your point that there Bitcoin has had more than its fair share of scams in its short life. However, for this particular idea to actually be a scam would take balls the size of Jupiter for only a minor payoff.

Getting press coverage, employing people, opening an office, listing shares, all for less than US$6,000,000? It just makes no sense.

So whilst investment might be risky at this stage, it's not the end-of-the-world scenario you're painting it to be.

It does concern me that we were promised news on Saturday, yet none has been delivered.

Danny, if you're reading I did say that we investors want news whether it's good or bad. Hiding bad news can be even worse than just explaining it.

You don't have to reveal exactly how it works - that might be your core IP that needs protecting later on.

Just treat it like a black box at this stage and tell us what it can do, why that's useful, who needs it, how much it'll cost them, how much profit you'll make. That's what business people care about - not the details of the technology.

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.

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.

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.

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?

ZipZap was for purchasing bitcoins. NeoBee is offering methods to save & spend them. Different propositions, but allied.

Could you tell us when you're revealing your more professional customer-facing websites?

If he has genuinely been thinking about this for 6 months, how come he hasn't considered any of the oppositions we've raised inside just a couple of days?

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.