Author Topic: [Rough Idea] Introduce 5% delegate rotation  (Read 3551 times)

0 Members and 1 Guest are viewing this topic.

Offline kokojie

  • Sr. Member
  • ****
  • Posts: 286
    • View Profile
I agree, there has to be some incentive for people to run standby delegates. It's difficult to keep updating/monitoring your delegate server, while have no chance being voted, receive 0 pay and forever be standby.

Also I agree there needs to be some criteria to be considered, the standby delegate must have:
* latest client version (most important, since this proves they are active)
* publishing feeds

and we can reserve some spots in the 101 delegates, just for randomly having stand by delegates start producing blocks. (or maybe keep the current 101 delegate limit, but add 10 more random spots, something like 101+10).

Offline Thom

I'm inclined to agree, this idea has merit. The particulars need to be discussed as well as the cost to implement, but I see little downside for the concept.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
I don't know if this is technically feasible, but here's the rough idea:

Every round, five random delegates are temporarily dropped and substituted with five random candidates from the top (say) 1000, for the duration of the round.
The next round they're of course reinstated, the temporary five are dropped back to standby and there's another draw.
This way the 101 "real" delegates are still signing 95% of blocks, while everyone in the next 900 has a chance to sign a block every couple of days.

This has several worthwhile effects:
1) allows standby delegates to prove themselves to potential voters
2) shuts up the anti-bts argument that we "only" have 100 validating nodes. Now we have a thousand! (for a price of 101)
3) allows more people to participate and invest themselves emotionally into the project
4) gives more weight to smaller stakes; incentivises voter participation
5) makes the theoretical 51 delegate attack slightly harder (attacker now needs to compromise 56 delegates)
6) makes a DOS attack an order of magnitude harder

Thoughts?

This is a very good idea. I endorse it.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline triox

  • Full Member
  • ***
  • Posts: 170
    • View Profile
  • BitShares: triox
These won't be some random nodes - they still have to front a registration fee and be actually voted into the top 1000 (under what I suspect would be a much flatter vote distribution). And what's the worst that a bad temporary delegate can do? He can NOT sign one block every 48 hours, big deal.

But of course this isn't something that is even viable at this stage. We have trouble finding even 101 unique people to run delegates as it is.
But when the network is orders of magnitude bigger and there are thousands of candidates?

Offline BunkerChainLabs-DataSecurityNode

I see a lot of problems with this.. and agree with Ander that it is unnecessary.

This is a financial system.. it would certainly lower my trust level of the network to know that 'random' delegates who could potentially be malicious to the network can just be added in. No need to worry about getting votes.. just setup a bunch of dummy delegates with the malicious attacks in wait and just let it roll. No accountability.. no real way to trace who might have done it... yeah.. this idea just keeps getting more horrible the more I think about it.

As the market cap increases to substantial levels.. so too is the level of trustworthiness the delegates will have to demonstrate to the public for maintaining a voted position. Only the really serious ones  that bring enough to the community to gain the votes are going to have entry into that arena and rightly so.

Instead of allowing for random delegates.. there should be more parameters for signals that vote in delegates... that can be further developed but not till later.. we got what we need for now.
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro and Sweeps!
+-+-+-+-+-+-+-+-+-+-+

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
Sounds bulletproof.

What could possibly go wrong?

What is the potential blowback?

I'm not seeing any negative effects of something like this.

What could go wrong:  It wastes a lot of developer time implementing this, and then doesnt really do much of anything, and the features we need get delayed. 

What could go wrong, even worse: There is a bug in the code which results in this leading to an exploit.

I'm not saying those are the case, I'm just saying thats the downside.


I dont think its worth developer time implementing this prior to 1.0.  There are more important things.  And probably later I would rather see work on proposals, prediction market,s and smart contracts than work on this.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline triox

  • Full Member
  • ***
  • Posts: 170
    • View Profile
  • BitShares: triox
allowed the number 1 delegate to not get paid that month

Round, not month. Every 17 or so minutes.
An elected delegate would only loose about 4 blocks a day - in exchange for a much better public perception for our blockchain.

Offline Pheonike


Now that I think more about it, there should be a point system outside of votes by which standby delegates can ranked. They earn points over time for using some metrics that way the best quialified standbys are ones picked.

Offline Pheonike


I dont think it based on the bottom 5 delegates. It should be based on the ones that are not fulfilling there technical duty of producing blocks and securing the network.

Offline Pheonike

It can be random for the standbys, but weighted towards any of 101 who are missing blocks, not providing price feeds, and running out dated versions.

Offline mdj

  • Full Member
  • ***
  • Posts: 192
    • View Profile
  • BitShares: mdj
I like this idea although perhaps not as many as 1000 - I gave up updating my delegate but will continue to do so as soon as I approach the 101 or am able to sign any blocks. So yeah, it's certainly motivation to keep the standby delegates up to date!

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: Ander
Interesting idea. 

Would this help make attacks harder, or would it make them easier?  If you got plenty of delegates into the top 1000, and then you waited until your turn came for them to produce blocks, you could get 5 extra delegates in there for that round. 

One issue is that the lower delegates probably wouldnt give price feeds and could be less reliable.

Of course, it does make the system even more complicated, and is 'yet another change', and it takes developer time away form other priorities that are probably more important. 
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline triox

  • Full Member
  • ***
  • Posts: 170
    • View Profile
  • BitShares: triox
I don't know if this is technically feasible, but here's the rough idea:

Every round, five random delegates are temporarily dropped and substituted with five random candidates from the top (say) 1000, for the duration of the round.
The next round they're of course reinstated, the temporary five are dropped back to standby and there's another draw.
This way the 101 "real" delegates are still signing 95% of blocks, while everyone in the next 900 has a chance to sign a block every couple of days.

This has several worthwhile effects:
1) allows standby delegates to prove themselves to potential voters
2) shuts up the anti-bts argument that we "only" have 100 validating nodes. Now we have a thousand! (for a price of 101)
3) allows more people to participate and invest themselves emotionally into the project
4) gives more weight to smaller stakes; incentivises voter participation
5) makes the theoretical 51 delegate attack slightly harder (attacker now needs to compromise 56 delegates)
6) makes a DOS attack an order of magnitude harder

Thoughts?