Quote from: monsterer on November 14, 2015, 10:59:01 PM

Quote from: clemahieu on November 14, 2015, 08:18:57 PM

Requesting a confirmation takes almost the same amount of resources as responding to one, I don't see a DDOS angle other than simple network flooding.

Well, since you don't store historical votes, everyone must be called upon to vote again if a syncing node is presented with a fork, no? You can't just take the opinion of one node at that point, surely?

Correct. If a node is syncing and it detects a fork, it sends N request packets to its peers. Each voting peer sends 1 response packet back to the sender with their vote. The initiator is committing equal network traffic compared to the responder.

This manual vote request only happens if the node is shut down while a fork is being negotiated and doesn't see the final conclusion. Because it's a lattice, it's only affecting the one account that intentionally created the fork, the rest of the chains are unaffected.

Quote

Quote

I still don't see bitcoin as completely trustless, determining the highest block is trustless but you still need to trust where you got your wallet and that it's implementing the protocol correctly.

These points are completely orthogonal to the problem we are discussing.

Quote

You also need a way to determine if you're connected to a partition, since there's no upper bound quarum on hashrate there's no trustless way to determine connectedness. With voting you can observe if you've received a quarum and make that determination.

Partition tolerance is the same in both cases; in bitcoin the votes are the blocks.

Partition tolerance, yes, partition detection is different though. With voting if I'm getting votes that sum to 15% of total supply, the network is split. With hashing if I'm getting a 1Mh/s rate is the network split? Maybe. I can guess if I know and trust an expected hash rate.