BitShares SAFE MODE - New Features Coming Soon

[ElMato]

So delegates will have two source of income?

income = 50 BTS * payrate + tx_fees*some_percentage

[vikram]

Then no more dilution model, or dilution+tx fee hybrid model we will have?

Hybrid model--current implementation keeps dilution as-is, and restores same fee model from before dilution was enabled.

[clayop]

Then no more dilution model, or dilution+tx fee hybrid model we will have?

[svk]

The git issue says:

To support a long-term sustainable design (without hard fork) we will pay a percentage of transaction fees to delegates as approved by bitshare holders.

Does this mean that we'll get to vote on the percentage of transaction fees that delegates get paid? How will this work?

From looking at the code I can tell you that it uses the same percentage pay rate as for dilution, so this means a pay-rise for all delegates and especially high-pay delegates.

While I can agree that long term this might be necessary for sustainability, as of right now it really isn't. How about phasing this in on the same schedule as dilution pay halvings instead? At the next halving, let 50% of fees be paid to delegates, then the one after 75%, then 87.5% etc.

[vikram]

The git issue says:

To support a long-term sustainable design (without hard fork) we will pay a percentage of transaction fees to delegates as approved by bitshare holders.

Does this mean that we'll get to vote on the percentage of transaction fees that delegates get paid? How will this work?

Current implementation does not do anything like that--it does the same thing we had before dilution.

[fluxer555]

The git issue says:

To support a long-term sustainable design (without hard fork) we will pay a percentage of transaction fees to delegates as approved by bitshare holders.

Does this mean that we'll get to vote on the percentage of transaction fees that delegates get paid? How will this work?

[vikram]

Could these futures help also potential attackers further?

Not really.  Unless the "attacker" controls delegate(s) and the "attack" is merely having those delegates refuse to include some transactions.

Someone please correct me if I'm wrong, but I believe each delegate gets some portion of tx fees for each transaction they include, specifically to discourage delegates from refusing to include transactions.  At any rate, I'm fairly sure this was a point I raised in pre-launch protocol discussions.

Since dilution was implemented; collected fees are currently destroyed. The old behavior will be restored after the next planned hardfork and fees will again be paid for producing a block: https://github.com/BitShares/bitshares/issues/954

[theoretical]

Could these futures help also potential attackers further?

Not really.  Unless the "attacker" controls delegate(s) and the "attack" is merely having those delegates refuse to include some transactions.

Someone please correct me if I'm wrong, but I believe each delegate gets some portion of tx fees for each transaction they include, specifically to discourage delegates from refusing to include transactions.  At any rate, I'm fairly sure this was a point I raised in pre-launch protocol discussions.

[liondani]

In light of the recent events we have identified the need for more robust options for delegates to keep the network alive without software changes.   I am going to work with the team today to provide some new features including:

1) Manual Addition of Checkpoints -  this will help delegates get on the proper fork if there is a fork.
2) Manual override on the maximum number of transactions to include per block, this would allow delegates to at the very least produce empty blocks or blocks with just 1 transaction at a time until issues can be resolved.   This would have allowed the delegates to resolve the most recent bug without dev team intervention.
3) Manual override on various other params such as: block size, block production time, pending transaction queue size, etc. 
4) Manual flagging of transactions as invalid for block production
5) Manual filtering of some transaction types (in case a bug is found with them).   

With these features delegates should be able to respond quicker and there will be more work around options.  Hopefully we will never need them, but like a spare tire it is good to have just in case.

If you can think of any other features delegates would need to have greater control over block production let me know.

Could these futures help also potential attackers further?

[Empirical1.1]

+5% +5% +5%

+5%

[cube]

+5% +5% +5%

[bytemaster]

In light of the recent events we have identified the need for more robust options for delegates to keep the network alive without software changes.   I am going to work with the team today to provide some new features including:

1) Manual Addition of Checkpoints -  this will help delegates get on the proper fork if there is a fork.
2) Manual override on the maximum number of transactions to include per block, this would allow delegates to at the very least produce empty blocks or blocks with just 1 transaction at a time until issues can be resolved.   This would have allowed the delegates to resolve the most recent bug without dev team intervention.
3) Manual override on various other params such as: block size, block production time, pending transaction queue size, etc. 
4) Manual flagging of transactions as invalid for block production
5) Manual filtering of some transaction types (in case a bug is found with them).   

With these features delegates should be able to respond quicker and there will be more work around options.  Hopefully we will never need them, but like a spare tire it is good to have just in case.

If you can think of any other features delegates would need to have greater control over block production let me know.