User talk:Holy-Fire

Please don't revert edits to spread your biased misinformation. These are the facts of the matter. --Luke-jr 15:13, 26 May 2011 (GMT)

Proof of Stake design outline

Constants (for example)

• POSGEN = 250000 // genesis block from which the fork (that includes the PoS protocol change) begins
  
• SIGBLOCK = 100 // signatures block at every SIGBLOCK block
  
• POWCONFIRMS = 6 // cementing rule for regular PoW after 12 blocks
  
• POSPOWRATIO = 0.5 // proportion of the reward at each PoS checkpoint that goes to stake holders
  
• SIGFEERATIO = 0.2 // proportion of fee that goes to miners who include PoS signatures in the block that they mined
  
• STAKECUTOFF = 50 // must hold at least STAKECUTOFF bitcoins to provide a signature
  

Protocol

Starting at POSGEN, every block B for which (B->count mod SIGBLOCK == 0) is considered to be a signatures block whose hash B->hash should be signed by privkeys that control at least STAKECUTOFF bitcoins, who would broadcast their signature via a message STAKEMSG to the Bitcoin network.

Each address should provide its STAKEMSG signature only once, to the best signatures block in a branch that it saw, and may choose to do saw anywhere between position B->count and (B->count)+SIGBLOCK (exclusive).

Nodes should re-broadcast these STAKEMSG messages that signed B->hash, and miners should include STAKEMSGs in the blocks between B->count and (B->count)+SIGBLOCK (exclusive).

The coinbase (txn fees + reward subsidy) of block (B->count)+SIGBLOCK is divvied up as follows:

• (i) coinbase*POSPOWRATIO is divided among the stake holders who signed block B->count
• (ii) coinbase*(1-POSPOWRATIO)*(1-SIGFEERATIO) goes to the miner who generated the block
• (iii) coinbase*(1-POSPOWRATIO)*SIGFEERATIO is divided among the miners who included STAKEMSGs in the last SIGBLOCK blocks

Note:

• In (i) we divide proportionally among stakeholders according to the amount of bitcoins that they control at block (B->count)+SIGBLOCK
• In (iii) we divide proportionally among miners according to the number of STAKEMSGs that they included in blocks

If an address with at least STAKECUTOFF bitcoins has provided STAKEMSG, then until block (B->count)+SIGBLOCK this address isn't allowed to do txn that lowers the amount of bitcoins that it controls below STAKECUTOFF.

Each ECDSA signature is 512 bits, the total number of bitcoins is 21000000, so 64 bytes * 21000000/STAKECUTOFF gives a theoretical limit of about 26 megabytes for the total size of STAKEMSGs in SIGBLOCK blocks, assuming that STAKECUTOFF==50 (the ECDSA pubkey can be extracted from the signature, therefore we can assume that the overhead is small). The theoretical limit is the worst-case scenario, in practice it's expected that addresses that control much more than STAKECUTOFF would participate in order to get higher proportion of the reward, etc.

Nodes should refuse to switch to a different branch with higher PoW difficulty if that forked branch starts more than POWCONFIRMS blocks before their current branch. The advantage of this is that it provides good security from double-spending by an attacker who prepares a secret fork, i.e. if after more than POWCONFIRMS you see that the distributed mining power continues to work on the branch that you have then it gives confidence that an attacker couldn't reverse a txn that occured in those POWCONFIRMS blocks. The disadvantage is that an attacker could try to create havoc and dilute the distributed mining power, by releasing his competing fork of POWCONFIRMS blocks and splitting the nodes into different branches because of network propagation time, but at the next signatures block after at most SIGBLOCK blocks it is highly likely that the network will re-unite.

Nodes should switch to a branch which replaces more than SIGBLOCK of the blocks in their current branch only if it has more signature blocks, and the sum of all bitcoins controlled by the addresses that provided the signatures in these blocks is larger (if an address participated in several of these signatures blocks then it is counted multiple times in the sum). Here too the advantage is that you can much more secure from double-spending attacks if the height of the relevant txn is more than n*SIGBLOCK blocks, because an attacker would have to collude with malicious stakeholders n times (as well as needing hashpower to create a secret fork of (n+1)*SIGBLOCK PoW blocks) in order to reverse this txn.

Another advantage is that the signatures blocks may be regarded as checkpoints, so they could replace the need for harcoded developers' checkpoints in the official client, which protects from malicious developers.