Author Topic: Delegated Proof of Stake (DPOS) White Paper  (Read 64233 times)

0 Members and 1 Guest are viewing this topic.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
And we nees some for a community newsletter

Offline solaaire

  • Full Member
  • ***
  • Posts: 177
  • praise the sun!
    • View Profile
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

Offline jae208

  • Hero Member
  • *****
  • Posts: 525
    • View Profile
Wow I must say that that is very impressive  8)

 +5% +5% +5% +5% +5% +5%
http://bitsharestutorials.com A work in progress
Subscribe to the Youtube Channel
https://www.youtube.com/user/BitsharesTutorials

Offline Stan

  • Hero Member
  • *****
  • Posts: 2908
  • You need to think BIGGER, Pinky...
    • View Profile
    • Cryptonomex
  • BitShares: Stan
I am pretty impressed on how fast things move currently ... having a hard time following all updates!! .. and thats a good sign imho +5%

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

+5%

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.

Anything said on these forums does not constitute an intent to create a legal obligation or contract of any kind.   These are merely my opinions which I reserve the right to change at any time.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I am pretty impressed on how fast things move currently ... having a hard time following all updates!! .. and thats a good sign imho +5%

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

+5%

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

Offline bytemaster

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

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

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I am pretty impressed on how fast things move currently ... having a hard time following all updates!! .. and thats a good sign imho +5%

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

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.

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

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
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.
« Last Edit: May 24, 2014, 12:38:09 am by HackFisher »
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.

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

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.

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile

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

Offline HackFisher

  • Hero Member
  • *****
  • Posts: 883
    • View Profile
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....
« Last Edit: May 23, 2014, 04:14:28 pm by HackFisher »
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.

Offline BitShares.com

  • Jr. Member
  • **
  • Posts: 21
    • View Profile
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.

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
I do not think a delegate is fired for not submitting a blockā€¦ other than that, interesting thoughts.
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.