Delegated Proof of Stake (DPOS) White Paper

[xeroc]

And we nees some for a community newsletter

[solaaire]

awesome work guys. this may seem like a strange request, but would any of you guys mind sharing some newer photos of the office, your workstations, or maybe a pic of the recently united crew? i know yall are busy and its an exciting time... but im excited too damnit! I wanna see some of the cool stuff thats happening over there, and i know im not the only one! Plus photos are very... tangible and can go a long way in helping people feel connected to a project or experience

[jae208]

Wow I must say that that is very impressive 

 

[Stan]

I am pretty impressed on how fast things move currently ... having a hard time following all updates!! .. and thats a good sign imho

The development team has really come together these past few weeks.  Things are happening faster, work is being divided more efficiently, communication is improving.   I can really feel the difference and the github commits will reveal it as well.

they do ...



Thanx for all the hard work to all of you!!!!

Here's the plot of software updates per day as the toolkit has matured, the team has learned to use it, and they started working together in a pizza-and-red-bull-powered pressure cooker in an underground bunker somewhere deep in the bowels of Blacksburg, VA...

Feel free to browse all the statistics at GitHub and see for yourself.

[xeroc]

I am pretty impressed on how fast things move currently ... having a hard time following all updates!! .. and thats a good sign imho

The development team has really come together these past few weeks.  Things are happening faster, work is being divided more efficiently, communication is improving.   I can really feel the difference and the github commits will reveal it as well.

they do ...



Thanx for all the hard work to all of you!!!!

[bytemaster]

I am pretty impressed on how fast things move currently ... having a hard time following all updates!! .. and thats a good sign imho

The development team has really come together these past few weeks.  Things are happening faster, work is being divided more efficiently, communication is improving.   I can really feel the difference and the github commits will reveal it as well.

[xeroc]

I am pretty impressed on how fast things move currently ... having a hard time following all updates!! .. and thats a good sign imho

[bytemaster]

I have updated the delegate selection routine to work as follows:

Once every N blocks I take the top N delegates by vote and perform a random shuffle using the current random seed.

No delegate will be able to gain control over the rounds and every delegate will get an opportunity exactly once per round.

[bytemaster]

Thinking about following case, two continuous delegate are happen to be the same, for example

Delegate Alice finds that she happen to be the delegates of two continuous block (she can check that while mining, 1% chance each block), x block, and x+1 block

So in the x block, Alice know that she will be the delegate of x+1 block (1% chance), and maybe she can selectively choose the secret_x for x + 1 to publish, to make the updated random seed[x+1] as she wish, making that she will be the delegate of x+2 block, and so on...

random seed updating might need to involve more secrets etc....

Random Seed Updating uses the following forumula:

R = HASH( R + revealed_secret ).

Alice will not know R until the future and thus in the present cannot choose secret for x+1.

In Alice's turn x, Alice will reveal the secret he created before, and current random seed R[ x ] is known of course, according to this he could calculate out next random seed R[x+1], to check whether x + 1 will or not be her turn.

If x and x + 1 are both Alice, and she knows that now in x, then she can selectively choose the secret which she will reveal in x+1, to make R[x+2] = HASH(R[x+1] + revealed_secret) and decide x+2 will be Alice's turn.

The condition is that Alice has to wait for two continuous turn x , x+1, which is not very difficult 1 - (99%)^x.

True that Alice could not determine who will be the next delegate, but with known that x, and x+1 are both her turn, she can choose to create attack and determine the delegate of x+2, in current seed update algorithm.

I see what you are saying... so you can essentially mine your way to controlling the network by selecting your secrets in such a way that you will always be selected.  It wouldn't even require very much mining.  And because one individual could control multiple delegates they could essentially hand control back and forth between delegates.   

To resolve this issue the 'random order' would have to be set at once and not change for a complete round.

[HackFisher]

Thinking about following case, two continuous delegate are happen to be the same, for example

Delegate Alice finds that she happen to be the delegates of two continuous block (she can check that while mining, 1% chance each block), x block, and x+1 block

So in the x block, Alice know that she will be the delegate of x+1 block (1% chance), and maybe she can selectively choose the secret_x for x + 1 to publish, to make the updated random seed[x+1] as she wish, making that she will be the delegate of x+2 block, and so on...

random seed updating might need to involve more secrets etc....

Random Seed Updating uses the following forumula:

R = HASH( R + revealed_secret ).

Alice will not know R until the future and thus in the present cannot choose secret for x+1.

In Alice's turn x, Alice will reveal the secret he created before, and current random seed R[ x ] is known of course, according to this he could calculate out next random seed R[x+1], to check whether x + 1 will or not be her turn.

If x and x + 1 are both Alice, and she knows that now in x, then she can selectively choose the secret which she will reveal in x+1, to make R[x+2] = HASH(R[x+1] + revealed_secret) and decide x+2 will be Alice's turn.

The condition is that Alice has to wait for two continuous turn x , x+1, which is not very difficult 1 - (99%)^x.

True that Alice could not determine who will be the next delegate, but with known that x, and x+1 are both her turn, she can choose to create attack and determine the delegate of x+2, in current seed update algorithm.

[bytemaster]

Thinking about following case, two continuous delegate are happen to be the same, for example

Delegate Alice finds that she happen to be the delegates of two continuous block (she can check that while mining, 1% chance each block), x block, and x+1 block

So in the x block, Alice know that she will be the delegate of x+1 block (1% chance), and maybe she can selectively choose the secret_x for x + 1 to publish, to make the updated random seed[x+1] as she wish, making that she will be the delegate of x+2 block, and so on...

random seed updating might need to involve more secrets etc....

Random Seed Updating uses the following forumula:

R = HASH( R + revealed_secret ).

Alice will not know R until the future and thus in the present cannot choose secret for x+1. 

[HackFisher]

random seed updating might need to involve more secrets etc....

Or guarantee that per round, each delegate can only produce one block in this round, the randomness could reducing in this case.

[HackFisher]

Thinking about following case, two continuous delegate are happen to be the same, for example

Delegate Alice finds that she happen to be the delegates of two continuous block (she can check that while mining, 1% chance each block), x block, and x+1 block

So in the x block, Alice know that she will be the delegate of x+1 block (1% chance), and maybe she can selectively choose the secret_x for x + 1 to publish, to make the updated random seed[x+1] as she wish, making that she will be the delegate of x+2 block, and so on...

random seed updating might need to involve more secrets etc....

[BitShares.com]

Just some ideas...

1. Have a parallel, secondary pool of unpaid 'dugout' delegates that create test blocks on a side-chain, so they can build reputation and build stats about latency, etc.. Clients are aware of this side-chain and change their votes according to these stats.

2. Have an unlimited number of delegates. Only the top 100 with the most votes get paid. Block creation alternates between the top 100 and the rest.

3. Some combination of the above two-- have 100 paid delegates, and 200 unpaid 'campaigning' delegates, from the top 300. Block creation alternates between the elected 100 and the campaigning 200. In order to become a campaigning delegate, you need to be a top contender from the dugout delegate side-chain, which holds an unlimited number of delegates.

[tonyk]

I do not think a delegate is fired for not submitting a block… other than that, interesting thoughts.