Author Topic: 101 delegates too many?  (Read 4388 times)

lamont

  • Newbie
  • *
  • Posts: 3
Re: 101 delegates too many?
« Reply #15 on: November 23, 2014, 01:12:07 am »


Another thought that is key. 

With too many delegates, there are not  proper incentives because they simply are not paid enough.  So by having less real delegates, there is more opportunity for people who are wanting to 51% attack by Sybil.

This makes sense.  101 delegates would not be paid enough to entice anywhere near 101 real delegates.  Fake delegates would have far more power since there would be no legitimate competition.

freetrade

  • Newbie
  • *
  • Posts: 31
Re: 101 delegates too many?
« Reply #16 on: November 23, 2014, 08:52:42 am »
I feel like I'm going round in circles with pc on this, with neither of us convincing the other. I don't think it's a critical issue, so I'm going to bow out with this my final statement -

I'm not convinced by pc's arguments and favor fewer delegates for the PTS project, (more than 20, fewer than 40) for reasons of improved security, transparency and efficiency.


fuzzy

  • Jr. Member
  • **
  • Posts: 78
Re: 101 delegates too many?
« Reply #17 on: November 23, 2014, 02:24:08 pm »
I have no clue why everyone is talking like this is set in stone...

This project is a NEW BEGINNING.  At first, it will need to be slightly more centralized to give delegates the pay required to build infrastructure, market, organize community and otherwise infuse value into the ecosystem.  The amount of delegates can be voted on when there are problems that a large number of community members agree necessitate an expansion in the number of said delegates. 

Let's not be too rigid here guys and girls.  Run a testnet and TEST it.  Then come back with results...and TEST it again until you find the perfect number of delegates given the current marketcap and adoption rate.  PTS can bring GREAT value to the entire DPOS ecosystem, if we take painstaking steps to test and learn...and teach others in the process. 

If you want PTS to be sharedropped on non-stop for the rest of eternity, you need it to be a DAC and Delegate Factory.  The lessons learned from testing things will make for a much more efficient Factory...and will ensure higher quality products are sharedropped on us.  Isn't that what we all want?

pc

  • CoreTeam
  • Jr. Member
  • *
  • Posts: 218
Re: 101 delegates too many?
« Reply #18 on: November 23, 2014, 05:58:24 pm »
It's not set in stone. There really is no right number of delegates. There are just lots of wrong numbers, like those below 14 or above 1002, and all non-prime numbers.

freetrade does have a point wrt transparency + efficiency, but we disagree on security.

We can't really test the problem either, as this is not about technology. I'm sure we can just change the number in the code, start a new test chain with 7 delegates (or 2003) and it will just work. That won't tell us anything about security or transparency though.

Anyway, we currently have bigger fish to fry than trying to find the ideal number of initial delegates.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de/
My PTS binary packages for CentOS, Fedora, openSUSE: http://software.opensuse.org/download.html?project=home%3Ap_conrad%3Abts&package=PTS
Please donate: pts:cyrano - thanks!

Empirical1

  • Newbie
  • *
  • Posts: 30
Re: 101 delegates too many?
« Reply #19 on: November 23, 2014, 10:57:14 pm »
Yeah it's not too serious but I don't think starting lower and increasing it to 101 as network fees allow is a bad idea.

fuzzy

  • Jr. Member
  • **
  • Posts: 78
Re: 101 delegates too many?
« Reply #20 on: November 24, 2014, 02:30:04 am »
I was under the impression that the only thing corrupt actors could do in DPOS was refuse to sign blocks...at which point they would be quickly voted out.  So why not simply keep it low starting out and go up? 

Can I get like a bulleted list of reasons for and against this?

pc

  • CoreTeam
  • Jr. Member
  • *
  • Posts: 218
Re: 101 delegates too many?
« Reply #21 on: November 24, 2014, 01:57:40 pm »
I was under the impression that the only thing corrupt actors could do in DPOS was refuse to sign blocks...at which point they would be quickly voted out.

If you have 51% of delegates you can have them sign blocks without publishing them.
You send lots of BTS to bter (for example). You wait until the transaction has been included in a block by one of the remaining 49% of delegates. Meanwhile, in your own private fork signed by 51% of the delegates you transfer the money to a different account belonging to yourself. After bter has credited your account, you publish the fork signed by your own delegates. The network should accept your fork because it has the majority of active delegates, and you have successfully double-spent your money.

Note also that the network can't vote you out, because with 51% of the delegates you can refuse transactions that vote against you.

  So why not simply keep it low starting out and go up? 

Can I get like a bulleted list of reasons for and against this?

- Changing the number of delegates requires a hard fork. (In theory, haven't tested this.) We want to avoid hard forks as much as possible.
- If we start with a number that's too low (i. e. less than the number of independent delegates) we are less decentralized (and therefore less secure) than we would be with a higher number.
- Starting with a higher number and having each delegate-person run multiple delegate-accounts is in almost every aspect equivalent to starting with a low number and having one delegate-account per delegate-person.
+ The presumably small fee volume is spread across many delegates, making running a delegate less attractive.
+ Freetrade argues that with a high number of delegates there is less accountability (my wording). I. e. it would be easier to hide a lot of fake identities in a large delegate crowd.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de/
My PTS binary packages for CentOS, Fedora, openSUSE: http://software.opensuse.org/download.html?project=home%3Ap_conrad%3Abts&package=PTS
Please donate: pts:cyrano - thanks!

fuzzy

  • Jr. Member
  • **
  • Posts: 78
Re: 101 delegates too many?
« Reply #22 on: November 26, 2014, 06:51:46 am »
- Changing the number of delegates requires a hard fork. (In theory, haven't tested this.) We want to avoid hard forks as much as possible.

It makes sense to want to minimize hard forkss...I guess the question though is whether or not it is worth it to do it early to get it perfect (if this is possible) or potentially have bigger problems down the road.  I don't know the right answer though so I'll leave it to the engineers ;)

- If we start with a number that's too low (i. e. less than the number of independent delegates) we are less decentralized (and therefore less secure) than we would be with a higher number.

I am not really necessarily against it being less decentralized in the early days.  In my opinion, if we have a group of core people early on we are more centralized (at first), but can be more agile... focusing efforts in areas where BTS has difficulty adapting.  There are some very important initiatives we need to head up in my humble opinion, if we want to establish ourselves as the "Berkshire Hathaway" of crypto-equities. 

1)  Funding general user education/best practices content
2)  Funding easy solutions for safely claiming sharedropped stake
3)  Funding for highly secure storage solutions for customer funds

I have many more, but these should be the first to be considered as they are things BTS has largely ignored due to its problems with too much decentralization for the number of tools available to adequately overcome. 

Why not be leaner and quicker on our feet compared to BTS, until a certain point?  Make a chart with various marketcaps and have it set up so we know that when we reach and sustain certain marketcap, that the system will be forked to allow for a larger number of delegates.  This way, as we grow, the forks are already predetermined (making them much less volatility-inducing) along with the increase in delegate number. 

I believe centralization in early stages is almost necessary to be able to overcome some of the biggest hurdles we face.  The biggest issue is making sure the whole project scales in such a way that lowers barriers to entry and divides power amongst a larger and larger group as the PTS network grows.   


- Starting with a higher number and having each delegate-person run multiple delegate-accounts is in almost every aspect equivalent to starting with a low number and having one delegate-account per delegate-person.
+ The presumably small fee volume is spread across many delegates, making running a delegate less attractive.
+ Freetrade argues that with a high number of delegates there is less accountability (my wording). I. e. it would be easier to hide a lot of fake identities in a large delegate crowd.

The bolded portion above is a very good point.   Perhaps it would be beneficial to do this instead of the prior solution offered.  However, I am still kind of curious how we will make it so those running delegates will gradually cede power to other delegates... 
If we are not careful, voter apathy will ensure the oldest delegates simply stay in power.  Over long periods of time, there is a very real concern of the centralization of stake (and thus voting power), which further ensures the early delegates never can be taken out of power. 

We need to come up with a plan...

pc

  • CoreTeam
  • Jr. Member
  • *
  • Posts: 218
Re: 101 delegates too many?
« Reply #23 on: November 26, 2014, 08:58:24 am »
However, I am still kind of curious how we will make it so those running delegates will gradually cede power to other delegates... 

If we are not careful, voter apathy will ensure the oldest delegates simply stay in power.  Over long periods of time, there is a very real concern of the centralization of stake (and thus voting power), which further ensures the early delegates never can be taken out of power. 

We need to come up with a plan...

Our immediate concern is a different one: we need to get sufficient stake voting for our initial delegates to prevent a medium-sized stakeholder (or group) from taking over the network.

It really is out of our hands after the chain has been launched. The voters decide who the delegates are. The rest is lobbying.
The only good thing here is that large stakeholders should have a high interest in protecting the chain and make therefore wise decisions, actively.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de/
My PTS binary packages for CentOS, Fedora, openSUSE: http://software.opensuse.org/download.html?project=home%3Ap_conrad%3Abts&package=PTS
Please donate: pts:cyrano - thanks!

fuzzy

  • Jr. Member
  • **
  • Posts: 78
Re: 101 delegates too many?
« Reply #24 on: November 26, 2014, 09:09:53 am »
However, I am still kind of curious how we will make it so those running delegates will gradually cede power to other delegates... 

If we are not careful, voter apathy will ensure the oldest delegates simply stay in power.  Over long periods of time, there is a very real concern of the centralization of stake (and thus voting power), which further ensures the early delegates never can be taken out of power. 

We need to come up with a plan...

Our immediate concern is a different one: we need to get sufficient stake voting for our initial delegates to prevent a medium-sized stakeholder (or group) from taking over the network.

It really is out of our hands after the chain has been launched. The voters decide who the delegates are. The rest is lobbying.
The only good thing here is that large stakeholders should have a high interest in protecting the chain and make therefore wise decisions, actively.

People severely underestimate the value of Mumble hangouts, imho.  I distinctly remember when the BTS merger proposal happened and the BTSX price started tanking.  We held an emergency Mumble Hangout and I literally watched as Dan talked and answered questions and the market slowly gained traction again. 

The reason for this is that the incentives are perfectly aligned to bring in the largest stakeholders.  Why?  Because the largest stakeholders are also the ones with the strongest incentive to want to ask the Dev questions...and to even hold them accountable.  Since it is a town-hall format where anyone can ask questions, they are generally very willing to show up.  If you want to get the biggest stakeholders together at the same time, the best way to do it is to have regular Dev Hangouts.

 Help me get a trusted delegate slate working (using this code made by xeroc:  https://github.com/xeroc/delegate-slate/blob/master/.gitignore) and we can make it one-click to vote for a large number of trusted INITIAL delegates.  After hangouts, I will say that if people appreciate my efforts, to please consider voting for the Beyond Bitcoin Delegate Slate...and the people who will be there will likely be those with the largest stake. 

This is a (partial?) solution to the stated problem.  People are not necessarily willing to tip, but I am almost certain that a delegate voting slate link would be easy to get them to click.   

pc

  • CoreTeam
  • Jr. Member
  • *
  • Posts: 218
Re: 101 delegates too many?
« Reply #25 on: November 27, 2014, 08:45:55 am »
Our immediate concern is a different one: we need to get sufficient stake voting for our initial delegates to prevent a medium-sized stakeholder (or group) from taking over the network.

I have thought about this and come up with an idea:

We can have the genesis stake vote for the initial delegates in a random distribution, with a target of (for example) 5% votes per delegate on average. This will secure the network from block #1.

The tricky part here is the fine tuning: choosing a low target makes attacks easier, choosing a high target means that the initial delegates will be difficult to get rid of when it becomes necessary.

@fuzzy: your suggestion regarding the delegate slate is good, we should do that in any case.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de/
My PTS binary packages for CentOS, Fedora, openSUSE: http://software.opensuse.org/download.html?project=home%3Ap_conrad%3Abts&package=PTS
Please donate: pts:cyrano - thanks!

cube

  • CoreTeam
  • Jr. Member
  • *
  • Posts: 293
  • Bit by bit, we will get there!
Re: 101 delegates too many?
« Reply #26 on: November 27, 2014, 10:33:28 am »
Our immediate concern is a different one: we need to get sufficient stake voting for our initial delegates to prevent a medium-sized stakeholder (or group) from taking over the network.

I have thought about this and come up with an idea:

We can have the genesis stake vote for the initial delegates in a random distribution, with a target of (for example) 5% votes per delegate on average. This will secure the network from block #1.

The tricky part here is the fine tuning: choosing a low target makes attacks easier, choosing a high target means that the initial delegates will be difficult to get rid of when it becomes necessary.

@fuzzy: your suggestion regarding the delegate slate is good, we should do that in any case.

I do not think tinkering the voting system this way is worth the risk.  At the root of the issue for all DPOS-based crypto is voter apathy.  A delegate slate can be a temporary work-around. We need to find a way to increase participation from the voters.
Contribute to the PTS Development Program!
Please send your donation to ID: bitcube

pc

  • CoreTeam
  • Jr. Member
  • *
  • Posts: 218
Re: 101 delegates too many?
« Reply #27 on: November 27, 2014, 10:50:39 am »
We can have the genesis stake vote for the initial delegates in a random distribution, with a target of (for example) 5% votes per delegate on average. This will secure the network from block #1.

The tricky part here is the fine tuning: choosing a low target makes attacks easier, choosing a high target means that the initial delegates will be difficult to get rid of when it becomes necessary.

@fuzzy: your suggestion regarding the delegate slate is good, we should do that in any case.

I do not think tinkering the voting system this way is worth the risk.

There is not much tinkering to be done. This is the relevant code in chain_database.cpp line 257:

Code: [Select]
            balance_record initial_balance( addr,
                                            asset( share_type( initial.low_bits() ), 0 ),
                                            0 /* Not voting for anyone */
                                          );

The big advantage is that we have built-in security against delegate takeover right from the start. After that, voters can settle in and appoint real delegates.

At the root of the issue for all DPOS-based crypto is voter apathy. 
We need to find a way to increase participation from the voters.

+1
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de/
My PTS binary packages for CentOS, Fedora, openSUSE: http://software.opensuse.org/download.html?project=home%3Ap_conrad%3Abts&package=PTS
Please donate: pts:cyrano - thanks!

cube

  • CoreTeam
  • Jr. Member
  • *
  • Posts: 293
  • Bit by bit, we will get there!
Re: 101 delegates too many?
« Reply #28 on: November 28, 2014, 10:17:13 am »
Thank you all for presenting your points and putting up a passionate debate and discussion.  A vigorously discussion/debate with input from various perspectives helps us to make a sound decision for PTS.

If there is no objection, we will take up pc's recommendation and turn on 'genesis stake vote'.
« Last Edit: November 28, 2014, 10:19:52 am by cube »
Contribute to the PTS Development Program!
Please send your donation to ID: bitcube

pc

  • CoreTeam
  • Jr. Member
  • *
  • Posts: 218
Re: 101 delegates too many?
« Reply #29 on: December 01, 2014, 01:58:25 pm »
We can have the genesis stake vote for the initial delegates in a random distribution, with a target of (for example) 5% votes per delegate on average. This will secure the network from block #1.

Implemented and push to develop branch. Vote ratio is configurable in pts_config.hpp.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de/
My PTS binary packages for CentOS, Fedora, openSUSE: http://software.opensuse.org/download.html?project=home%3Ap_conrad%3Abts&package=PTS
Please donate: pts:cyrano - thanks!