Could bitshares completely eliminate forks, and therefore double spends?

[monsterer]

Are you saying if even only 1 node has a network issue (or disagrees w/ the others), the whole chain will stall?
I guess such a system could be considered "forkless" but it will be susceptible to crippling DDOS attacks.

If a majority delegate consensus cannot be formed, then the worst case is consensus stalls. A single disagreement cannot halt consensus.

[roadscape]

Under this model, there is no possibility for a fork to form, either consensus continues to progress, or it stalls completely. With no forks, there can be no double spends and transactions can be accepted with confidence as soon as they enter a block.

Are you saying if even only 1 node has a network issue (or disagrees w/ the others), the whole chain will stall?
I guess such a system could be considered "forkless" but it will be susceptible to crippling DDOS attacks.

[roadscape]

Call it what you will, there will always be forks, imho. The key is to have good fork-handling.

Why will there always be forks?

Because there will always be disagreement at some level.. I guess I don't understand how these block producers come to consensus. Would such a system be otherwise DPOS-based?

[xeroc]

Call it what you will, there will always be forks, imho. The key is to have good fork-handling.

Why will there always be forks?

What you are proposing is a "parallel" processing of transactions such that delegates coordinate on the next block
in contrast to the sequential processing of transaction .. one delegate at a time ..
The idea sounds interesting .. it may work, but with more network load, because you need delegates to exchange their current state of confirmation kind of ..
And you let only those transactions confirm into a block (however that would be derived with this scheme) that has more than 51% of the delegates confirm

Is that about what you are proposing? I like the idea .. never thought of it really

[monsterer]

Call it what you will, there will always be forks, imho. The key is to have good fork-handling.

Why will there always be forks?

[roadscape]

Couldn't 51% collude and censor transactions? I recall BM saying our network would be able to recover even with only 5% honest delegates. How well would this model handle hostile delegates?

Call it what you will, there will always be forks, imho. The key is to have good fork-handling.

I'd like to see wallets that are fork-aware, report them immediately, and have the user either wait it out or choose the right fork.

[monsterer]

- What if a delegates backup scheme misbehaves and a signs two different blocks at the same time?
- What if due to propagation delays, the delegate C sees valid blocks from B and A although B did not see A's block "in-time"?

These examples result in a fork (i.e. a delegate has to decide for one of the options) .. not sure this can be prevented without the loss of decentralized trust?
For ripple this is not a problem because they pre-define the consensus by "their" set of trusted notes.

If you could eliminate forks, that would be awesome, but I don't see how this can be easily achieved without having other disadvantages.

All delegates vote on the candidate transaction set at the same time, choosing the majority common set achieves consensus, stick them all in a block, postpone the other transactions until the next block.

[xeroc]

- What if a delegates backup scheme misbehaves and a signs two different blocks at the same time?
- What if due to propagation delays, the delegate C sees valid blocks from B and A although B did not see A's block "in-time"?

These examples result in a fork (i.e. a delegate has to decide for one of the options) .. not sure this can be prevented without the loss of decentralized trust?
For ripple this is not a problem because they pre-define the consensus by "their" set of trusted notes.

If you could eliminate forks, that would be awesome, but I don't see how this can be easily achieved without having other disadvantages.

[monsterer]

So does it in Bitcoin .. difference is that in Bitcoin you need alot of POW-power to do a successfull double spend, while in DPOS you need alot of trust/votes to do a double spend AND have to fear the consequences of being fired without honors!

I am asking if its possible to completely remove the chance of a double spend by eliminating forks.

[xeroc]

But, at 1 confirmation the possibility of a double spend remains.

So does it in Bitcoin .. difference is that in Bitcoin you need alot of POW-power to do a successfull double spend, while in DPOS you need alot of trust/votes to do a double spend AND have to fear the consequences of being fired without honors!

[monsterer]

Bitshares already has the lowest forking rate and duration out there.

But, at 1 confirmation the possibility of a double spend remains.

[sittingduck]

Bitshares already has the lowest forking rate and duration out there.


Sent from my iPhone using Tapatalk

[monsterer]

I don't think I fully understand your description, but I believe you've just (at least partly) described Ripple Consensus.

This is true - ripple operates this way, but is only resilient to attack because they control all the block producers since they lack any recourse against bad actors. Bitshares is more decentralised than ripple, but is in the same unique position to take advantage of a forkless blockchain while also having a recourse defence against bad actors.

[vikram]

I don't think I fully understand your description, but I believe you've just (at least partly) described Ripple Consensus.

[monsterer]

I make the following assumptions:

* Forks are the only thing which make a double spend attack possible

* A forkless blockchain has no need for an amortised consensus

A forkless blockchain is only possible where all nodes are aware of who the block producers are, because otherwise you could have islands of nodes with separate consensus from the main group with their own block producers. If a node finds itself cut off from all the block producers, it must wait to reconnect - consensus stalls for such a node.

Network latency can cause forks in an amortised consensus because the set of candidate transactions can be different between block producers at block production time. However, if consensus happens simultaneously, picking the majority common transaction set between block producers would eliminate the problem with latency - all delegates come to an agreement about their common transactions, which get put into a block, and the remaining transactions are simply postponed.

Under this model, there is no possibility for a fork to form, either consensus continues to progress, or it stalls completely. With no forks, there can be no double spends and transactions can be accepted with confidence as soon as they enter a block.

Thoughts?