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

Empirical1

  • Newbie
  • *
  • Posts: 30
101 delegates too many?
« on: November 18, 2014, 01:52:53 am »
I've noticed Rand Paul Coin is looking to start with only 13 delegates, that's too few imo, but I think there is an argument for fewer delegates especially in a no inflation DAC. (Lower cost.)

I also think nobody knows who the 101 delegates in BTS are, but fewer might get more attention, interest and be more accountable. Even 51 seems like a lot in practice to me. What do others think?

freetrade

  • Newbie
  • *
  • Posts: 31
Re: 101 delegates too many?
« Reply #1 on: November 18, 2014, 08:00:19 am »
I think we should pick a different number, even if just to differentiate from other DPOS assets.

How about 23?

pc

  • CoreTeam
  • Jr. Member
  • *
  • Posts: 218
Re: 101 delegates too many?
« Reply #2 on: November 18, 2014, 08:29:30 am »
We've already discussed that topic:


I am not sure about the impact on the PTS network security if we are to lower the 101 delegate count.  My view is not to change it unless we know how it would impact the security.

Yes, it was probably a stupid idea. Lowering the number doesn't help us at all, it only makes a 51% attack easier.

For a successful 51% attack, the attacker must control more than 50% of the delegates. So for a 51% you need to control only 37 out of 73 delegates, as opposed to 51 out of 101. In reality this will only start playing a role when we have more than 73 different people running a delegate each. This is unlikely to happen soon, so in the short term my idea wouldn't impact security in any way, but in the long run it would make things worse.

IMO 13 delegates is ridiculous. Even if you have 13 different people each running a delegate, only 7 of these must coordinate for a 51% attack. Supposing you have 13 people willing to run delegates it doesn't matter cost- or security-wise if each one of these runs 1 delegate or 8 (hint: you can have many active delegate accounts in one wallet). But in the instant that a 14th guy comes along and offers to run a delegate it *does* matter. Suddenly you need to coordinate more than 7 people for a successful attack, without changing the network parameters. The 14th guy also doesn't change the cost to the network, as delegates are currently paid only from tx fees. That's why starting with 101 delegates doesn't cost anything, but saves you a hardfork later when more delegate-people are available.

Now, the real problem is that for the start we probably won't have even 13 people. We need volunteers, so if you want to run one or more delegates right from the start give us a pubkey or two and if it's up to me I'll include your delegate in the genesis block.
« Last Edit: November 18, 2014, 08:31:23 am by pc »
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 #3 on: November 18, 2014, 09:29:52 am »
I think we should pick a different number, even if just to differentiate from other DPOS assets.

How about 23?

We should have sufficient number of delegates to minimise the chance of attack via collusion among delegates.  101 seems a 'safer' number to start with.

What is your concern to have a smaller number of '23'?
Contribute to the PTS Development Program!
Please send your donation to ID: bitcube

fuzzy

  • Jr. Member
  • **
  • Posts: 78
Re: 101 delegates too many?
« Reply #4 on: November 18, 2014, 10:15:53 am »
I've noticed Rand Paul Coin is looking to start with only 13 delegates, that's too few imo, but I think there is an argument for fewer delegates especially in a no inflation DAC. (Lower cost.)

I also think nobody knows who the 101 delegates in BTS are, but fewer might get more attention, interest and be more accountable. Even 51 seems like a lot in practice to me. What do others think?

I think RPCDev stated that with 13 delegates, tx times would approximate at 20seconds.  He/She did it because it represented the first 13 colonies of these United States.  Imho, this is perfect as 13 state campaign headquarters could each run a delegate that gets voted in.  They would likely direct 100% of tx fees to the campaign AND promote it in order to ensure a huge marketcap (which just  makes them more money over time). 

freetrade

  • Newbie
  • *
  • Posts: 31
Re: 101 delegates too many?
« Reply #5 on: November 18, 2014, 06:45:56 pm »

IMO 13 delegates is ridiculous. Even if you have 13 different people each running a delegate, only 7 of these must coordinate for a 51% attack. Supposing you have 13 people willing to run delegates it doesn't matter cost- or security-wise if each one of these runs 1 delegate or 8 (hint: you can have many active delegate accounts in one wallet).

I think attacks are more likely to come from 1 person running multiple delegates rather than multiple people co-ordinating.

So in the example above, you'd need 1 guy running 7 delegates. I don't see that it's much more difficult to control 7 out of 13 delegate than it is to control 51 out of 101 delegates.

Indeed, it might be easier for one person to hide 51 delegates among 101, because no-one can keep track of who is running the 101 delegates. Whereas if there 13 delegates you'd be easily able to keep track of who had which delegate.

So perhaps more delegates is not always better - especially with a DPOS asset with lower community interest. There's a balance to be reached, for PTS, probably greater than 13, probably less than 101.

cube

  • CoreTeam
  • Jr. Member
  • *
  • Posts: 293
  • Bit by bit, we will get there!
Re: 101 delegates too many?
« Reply #6 on: November 19, 2014, 08:01:30 am »

I think attacks are more likely to come from 1 person running multiple delegates rather than multiple people co-ordinating.

So in the example above, you'd need 1 guy running 7 delegates. I don't see that it's much more difficult to control 7 out of 13 delegate than it is to control 51 out of 101 delegates.

Indeed, it might be easier for one person to hide 51 delegates among 101, because no-one can keep track of who is running the 101 delegates. Whereas if there 13 delegates you'd be easily able to keep track of who had which delegate.

So perhaps more delegates is not always better - especially with a DPOS asset with lower community interest. There's a balance to be reached, for PTS, probably greater than 13, probably less than 101.

Could you elaborate on the 'bold' part?
Contribute to the PTS Development Program!
Please send your donation to ID: bitcube

freetrade

  • Newbie
  • *
  • Posts: 31
Re: 101 delegates too many?
« Reply #7 on: November 19, 2014, 08:22:52 am »

I think attacks are more likely to come from 1 person running multiple delegates rather than multiple people co-ordinating.

So in the example above, you'd need 1 guy running 7 delegates. I don't see that it's much more difficult to control 7 out of 13 delegate than it is to control 51 out of 101 delegates.

Indeed, it might be easier for one person to hide 51 delegates among 101, because no-one can keep track of who is running the 101 delegates. Whereas if there 13 delegates you'd be easily able to keep track of who had which delegate.

So perhaps more delegates is not always better - especially with a DPOS asset with lower community interest. There's a balance to be reached, for PTS, probably greater than 13, probably less than 101.

Could you elaborate on the 'bold' part?

I mean if we have 10 active members with 1 delegate each, and require 101 delegates, that's 91 delegate spots up for anonomous, and potentially bad actors.

Principle is that it is easier for bad actors to hide in a large city than in a small village.

randpaulcoindev

  • Newbie
  • *
  • Posts: 39
Re: 101 delegates too many?
« Reply #8 on: November 21, 2014, 06:19:33 am »

There are these init-delegates that appear to be running by whoever initializes the chain.  Starting out with 101 delegates is going to take a serious VPS.

FreeTrade is right - it is not really any easier to 51% attack via sybil-delegate attack with 13 delegates.  It is not any easier 51% attack via owning stake.

13 was chosen because it is a workable number. It appears to be a simple constant in a header file. I'm working under the assumption it can be easily changed.  Indeed, if the market cap of RPCD goes up by much then we will look to add delegates.

With 13 delegates, the transaction fees are split by 13 people.  This makes far more economic sense for a chain that is starting out with an unknown market cap.  It is also easier to have 13 fully unique delegates.  These incentives give better security for a coin that might not have a large cap at the beginning.  101 delegates is a big fail all over although is a lot more appropriate for something like BTS.

freetrade

  • Newbie
  • *
  • Posts: 31
Re: 101 delegates too many?
« Reply #9 on: November 21, 2014, 06:52:09 am »
13 was chosen because it is a workable number. It appears to be a simple constant in a header file. I'm working under the assumption it can be easily changed.  Indeed, if the market cap of RPCD goes up by much then we will look to add delegates.

I'm assuming this would be a forking change?

pc, have you re-considered your position in the light of these arguments? If not, can you tell us why?

pc

  • CoreTeam
  • Jr. Member
  • *
  • Posts: 218
Re: 101 delegates too many?
« Reply #10 on: November 21, 2014, 01:27:57 pm »

There are these init-delegates that appear to be running by whoever initializes the chain.  Starting out with 101 delegates is going to take a serious VPS.

Our plan is to find at least 3 volunteers and split the initial delegates among those. More will be better of course, as long as there are reliable candidates.
You don't need a serious VPS to run 101 delegates. I have split the 101 delegates of our PTS test network on 2 servers. The trick is that you don't need to run 101 instances of the wallet in parallel, instead you can load all of your delegates into a single wallet and open that in a single instance.

13 was chosen because it is a workable number. It appears to be a simple constant in a header file. I'm working under the assumption it can be easily changed.  Indeed, if the market cap of RPCD goes up by much then we will look to add delegates.

I don't think you can change to constant so easily. The order in which delegates have to generate blocks depends on the total number of delegates. If you start a chain with 13 delegates and later increase the number, the newly compiled client will most likely choke on your blockchain, because it will look like delegates created block when it wasn't their turn. I suggest you try this out before starting your chain.

With 13 delegates, the transaction fees are split by 13 people.  This makes far more economic sense for a chain that is starting out with an unknown market cap.  It is also easier to have 13 fully unique delegates.  These incentives give better security for a coin that might not have a large cap at the beginning.  101 delegates is a big fail all over although is a lot more appropriate for something like BTS.

101 initial delegates != 101 different people. In fact we would be very happy if we had 13 different people reliably running initial delegates. But once we have 14 different people we will instantly have better security with 101 delegates than with 13, without requiring a hard fork.

You're arguing that it is easier to have 13 fully unique delegates. I agree. However, I also think it is much easier to generate the 7 fake identities required for a 51% attack.
I'm working on the assumption that we won't have 101 unique delegates, but that we can split the delegates across the people we have and scale from there. In the beginning we won't be better off than with only 13 delegates, but we will be better as soon as we have 14 unique persons.
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!

randpaulcoindev

  • Newbie
  • *
  • Posts: 39
Re: 101 delegates too many?
« Reply #11 on: November 21, 2014, 04:32:18 pm »


This is definitely some great insight. I will need to rethink and test things. Once I get a decent snapshot then we'll move to testnet.

Are 13 delegates actually more or less secure?  I suppose it might depend on the size of the initial community and how many distinct identities are willing to take over roles.

randpaulcoindev

  • Newbie
  • *
  • Posts: 39
Re: 101 delegates too many?
« Reply #12 on: November 21, 2014, 09:32:00 pm »


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.

freetrade

  • Newbie
  • *
  • Posts: 31
Re: 101 delegates too many?
« Reply #13 on: November 22, 2014, 05:31:21 am »
However, I also think it is much easier to generate the 7 fake identities required for a 51% attack.

I think it is just as easy to generate 7 fake identities running 8 delegates each. This is the key point that you haven't refuted.

Another question, if more delegates are better, why stop at 101. Why not 103 or 1003?

 

pc

  • CoreTeam
  • Jr. Member
  • *
  • Posts: 218
Re: 101 delegates too many?
« Reply #14 on: November 22, 2014, 09:13:34 am »
However, I also think it is much easier to generate the 7 fake identities required for a 51% attack.

I think it is just as easy to generate 7 fake identities running 8 delegates each. This is the key point that you haven't refuted.

Again: with 101 initial delegates we're no better or worse than with 13 initial delegates - as long as we don't have more than 13 independent people willing to run them. But at the moment we have 14 independent people we will be better off with 101 initial delegates. At that point it will no longer be sufficient to create 7 fake identities, you will need 8.

Another question, if more delegates are better, why stop at 101. Why not 103 or 1003?

101 is an arbitrary number chosen by bm, yes. Actually I think he chose 100 first and later he realized that this could easily result in two forks with 50 delegates each. With 101 there's always a majority.

Any other arbitrary (odd) number could be chosen as well, yes. But a higher number is only a real improvement if you have enough independent people willing to run them. It is unlikely that we will find 1003 different people willing to run reliable delegates. It is less unlikely that we will find 101, and I think it's almost certain that we will find more than 13 over time.
OTOH, more delegates certainly create more overhead. I don't know how significant that is, but it means we have to make a tradeoff between the potential security improvement of more initial delegates and the additional overhead created by more initial delegates. I really don't care if it's 97 or 101 or 103, but IMO it should be much more than 13 and much less than 1003.
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!