Consensus on the list of delegates

[arhag]

The easiest part is to increase interval between blocks 51-fold. Then to make majority of delegates to sign every single block together. => 1 confirmation is as reliable as 51 confirmations in old design, but as a free bonus you are now protected against network fragmentation because if you don't see the next superblock for a long time then you are eclipse-attacked or delegates can't find each other.

While I don't think the attack you are suggesting is a serious issue and I don't really see how your suggestion prevents the 51+ delegate collusion attack, I have proposed something similar to what you suggested but without changing block interval requirements. The idea is that in typical scenarios, we should have greater than 80% delegate confirmation of the state of the blockchain within 20 seconds.

Next step is setting a requirement to "refresh" votes every week with the quorum set to 51% of the stake. If less than 51% of the stake takes part in the voting then network stalls automatically. => DACs should be happy + employees can't abuse their power.

It is already possible in theory to measure how much of the stake has participated in voting where the votes are not older than a given time. I don't think there is any reason to make this a hard requirement in the blockchain. If a user feels uncomfortable with the percentage of the stake that has updated their votes in the last month, for example, or especially if their vote update transactions are being ignored by the delegates, then they could perhaps start communicating their suspicions with others and start organizing a potential hard fork. In the forked chain (I will call BTS'), which snapshots off a recent block in the main chain, they can all vote on whether their vote update transactions have been filtered by the delegates in the main chain and that they wish to start with a new clean slate of delegates. If you reach some quorum on this fact (+ the new set of 101 delegates to take over the new chain) on that new chain (say >50%), then the stakeholders will initiate yet another hard fork of the original BTS chain.

The second hard fork is to incorporate in the snapshot all the updates to stake and BitAsset ownership during the time between the first snapshot and the second snapshot, which should be very soon after the point at which 50% consensus is reached on the first fork. Then on this second forked chain (BTS''), a quorum of 75%, for example, would be necessary for the chain to begin as the new BTS and for the original chain (BTS) to be considered an invalid fork (and hopefully merchants and exchanges will also agree to this new consensus) . People will dump the stake of the old chain (killing the old chain's market cap) and start using BTS'', now rebranded BTS, of the new chain like the real BTS. Any transfer on the original chain after the point of the second snapshot might be void (double spend), but the users should have likely stopped transferring stake on the original chain, just to be safe, when they realized that 50% consensus was reached on a fork.

[Ander]

Democracy can be 51% attacked.

[gamey]

So then what would be the point of doing all this?

The point is just to show that power that controls election will stay on the top forever. This is what we observe in a lot of dictatorship countries where elections are faked.

Basically, it's possible for any election on the planet earth to be "bought" in one way or another. So you're saying that elections are always suspect? That BitShares delegates will care more about a potential small bribe than about their longer term financial interest and fiduciary duty to act in the best interests of BitShares? I certainly don't see this as a solid possibility.

This is an interesting thread but it can be summed up with a few points

51%" attacks at various levels/layers.  In Bitcoin, 51% of the pools could attack or 51% of the hashing power.  51% of the pools could immediately start doing this attack in BTC.  That is nothing new.

All elections/consensus can be 51% attacked.

The reality is that there is a human component so if this happened it could be forked around. It would be very pricey for the attackers. It would be an interesting thing to observe if it were to actually happen.  (Whose disruptive/attacking stake is removed?)

I'm not sure how NXT works, but it seems likely we could concoct very similar attacks to NXT.  Once 51% of those mining/forging pools fall under the control of the same entity, they could ignore the blocks of the minority and thus reap all the transaction fees themselves. Is this not correct?  The only difference is the magnitude at which people are being paid.  How does NXT fix this 51% problem ?

[Troglodactyl]

Hmm,

I feel that BTS with a 10 second block time and the possibility of an avenue of attack that requires users to agree to hard fork to recover is probably better than BTS with an almost 10 minute transaction time but safer from attack.
...

...but recovery wouldn't require a hard fork in the current system, and in a system where the majority of delegates had to sign each block, as CfB is proposing, recovering would require a hard fork if the majority of delegates were hostile.

[Come-from-Beyond]

Well, with 200 ms latency you still get 10 sec blocks.

No idea how to fix 51% stake requirement though.

[Ander]

The easiest part is to increase interval between blocks 51-fold.

I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.

Yes this, 10 second transactions are important for running an Exchange. 
Its not worth it to kill the functionality of the DAC in order to secure it more.

[Ander]

Hmm,

I feel that BTS with a 10 second block time and the possibility of an avenue of attack that requires users to agree to hard fork to recover is probably better than BTS with an almost 10 minute transaction time but safer from attack.


Part of the idea behind all Proof of Stake variations is that it might be worth trading off some security in order to greatly improve other aspects of the blockchain such as speed and reduced cost of network security, provided that you can make it still "expensive enough" to execute an attack that no one will want to do it. 


I think it would be quite hard to get 51 delegates elected who all are agreeing to collude in a way detrimental to bitshares.  If the plan involves bribing other delegates, I think at least one of the delegates you approach will believe that a reputation gain they can get from exposing the scheme to everyone and helping defeat it will outweigh any possible payment. 


I think that all of this is worth empirically testing by trying to attack DevShares.   We might learn interesting things.  If one could successfully attack DevShares and show that it wasnt expensive enough to do, then changing Bitshares in whatever way is needed to avoid the attack is probably worth it.

[Chronos]

I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.

If you include 51x more transactions then tx/sec ratio will be the same.

This would still worsen the exchange, because the blockchain frontruns you. See http://bytemaster.bitshares.org/article/2015/01/29/How-BitShares-Prevents-Front-Running/.

[Troglodactyl]

I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.

If you include 51x more transactions then tx/sec ratio will be the same.

Also that would make our network almost as painfully slow as Bitcoin.

[Troglodactyl]

The easiest part is to increase interval between blocks 51-fold.

I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.

Yes. This would mess up the markets badly, as well as requiring voters to revote just to keep the network from freezing even when delegates were doing a fine job.  Remember the uproar when having an inactivity fee was proposed? Same thing, plus tragedy of the commons, since the whole network freezes if enough individual voters don't actively keep it alive.

I still don't see any issues this is intended to correct as very serious.

[Come-from-Beyond]

I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.

If you include 51x more transactions then tx/sec ratio will be the same.

[Chronos]

The easiest part is to increase interval between blocks 51-fold.

I could be wrong, but I think a widened block timing would negatively affect the on-blockchain BTS/BitAsset exchange by matching orders less often.

[Come-from-Beyond]

The easiest part is to increase interval between blocks 51-fold. Then to make majority of delegates to sign every single block together. => 1 confirmation is as reliable as 51 confirmations in old design, but as a free bonus you are now protected against network fragmentation because if you don't see the next superblock for a long time then you are eclipse-attacked or delegates can't find each other.

Next step is setting a requirement to "refresh" votes every week with the quorum set to 51% of the stake. If less than 51% of the stake takes part in the voting then network stalls automatically. => DACs should be happy + employees can't abuse their power.

PS: This is just suggestions, without modelling I can't say if this will work as intended.

[sschechter]

Can't you guys just change the rules slightly and get rid of the issue?

What is your idea for a rule change that would make things better?

After all this discussion, I'm curious to know your fix

[Ander]

Can't you guys just change the rules slightly and get rid of the issue?

What is your idea for a rule change that would make things better?