Quote from: SapphireSpire on March 17, 2016, 04:47:38 PM

Quote from: DannyHamilton on March 17, 2016, 02:04:19 PM

How do I know when a transaction "has been accepted by a majority of the network"? What is the specific technical process that allows me to know exactly when that has happened?

An optimized network needs to be organized into a tree-like structure, with some nodes serving as trunks, some as branches, and some as leaves. The topography of a large network would always be changing as nodes connect and disconnect. Nodes can be elevated from leaf to branch to trunk depending on bandwidth and how long they've been connected. The higher the level of elevation of a node the more lower level nodes depend on it for messaging. If an elevated node disconnects, one of it's dependents can be promoted or they can switch to another node of the same level. This way transaction messages can be distributed from any one node to all other nodes on the network without any node receiving the same message twice. Once a transaction has reached every node on the network, acceptance of that transaction would bounce back in reverse direction until it returns to the node who originated the transaction message- the recipient. The recipient can then broadcast the transaction with Proof of Acceptance (POA).

So, if I'm running a trunk node, then I can send one transaction to one of my branches, and a double-spend transaction to my parent node and all the other branches? Since messages are distributed in a hierarchy and I can choose to send a message to my branches "without any node receiving the same message twice", those nodes won't realize that they have accepted a double spend?

If the recipient is in the branch that gets my first message, then I'll know because I'll receive their POA, but I won't relay the POA to any other branches (or my parent node). Instead, I'll broadcast to those other branches my own POA for the double-spend transaction.

When attempting to invent a new solution to a problem that has been analyzed for many decades, it isn't very important to figure out how your invention would work. Lots of people have ideas that, until they put some real thought into the risks, they think would work. It is VERY important to think about how your invention would fail. Generally, if someone doesn't describe most of the significant failure points in their concept when proposing a new solution to replace bitcoin, I can be pretty confident that they haven't really given their invention much thought and it almost certainly won't work.

Please take the time to think through all the ways your system could fail. Then either describe why that failure isn't a significant threat, or find a way to protect against the failure. Once you've got it all worked out, I'd love to hear what your well thought out solution is with all it's potential failures.

Quote from: monsterer on March 17, 2016, 04:57:41 PM

This is not a trustless system.

Exactly. Every node must trust that all the peers above them in the tree have not attempted to isolate them from the rest of the network.