Author Topic: BitShares SAFE MODE - New Features Coming Soon  (Read 2957 times)

0 Members and 1 Guest are viewing this topic.

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 288
    • View Profile
So delegates will have two source of income?

income = 50 BTS * payrate + tx_fees*some_percentage

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

Offline clayop

  • Hero Member
  • *****
  • Posts: 2033
    • View Profile
    • Bitshares Korea
  • BitShares: clayop
Then no more dilution model, or dilution+tx fee hybrid model we will have?
Bitshares Korea - http://www.bitshares.kr
Vote for me and see Korean Bitshares community grows
delegate-clayop

Offline svk

The git issue says:

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

Worker: dev.bitsharesblocks

Offline vikram

The git issue says:

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

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile
The git issue says:

Quote
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?

Offline 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

Offline 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.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: 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?


Offline cube

  • Hero Member
  • *****
  • Posts: 1404
  • Bit by bit, we will get there!
    • View Profile
  • BitShares: bitcube
ID: bitcube
bitcube is a dedicated witness and committe member. Please vote for bitcube.

Offline 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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.