Quote from: monsterer on November 14, 2015, 06:49:15 PM

Quote from: clemahieu on November 14, 2015, 05:01:38 PM

It seems like the analogous situation in bitcoin is being fed shorter block chains that were dropped. When synchronizing we don't give shorter chains to people because it's irrelevant, we only give people the longest one a.k.a the contemporary state.

What would voting history give? What if they only replay certain votes? History is really unnecessary.

In bitcoin you can give any node any set of chains - the node simply chooses the longest one; this is trustless and always consistent.

If you had voting history in raiblocks, at least the synchronizing client could make some kind of judgement based on several forks which it is presented with. As it stands, it has to ask other nodes which is correct, which is not a trustless operation and on top of that, said nodes must expend their own resources to re-vote on the historical forks (the DDOS angle, I've previously mentioned).

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.

We also use stateless UDP rather than TCP so far fewer network resources are consumed.

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. 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.

I guess it's an engineering tradeoff, do we want fast confirmations and unbounded global throughput at the expense of edge-case trust which I still find fairly impractical.