Difference between revisions of "User talk:Holy-Fire"

From Bitcoin Wiki
Jump to: navigation, search
(simplified by removing the need to give proportional reward to miners)
(Proof of Stake design outline: +client behavior)
Line 33: Line 33:
  
 
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.
 
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.
 +
 +
=== Client behavior (+more protocol rules) ===
 +
 +
We wish to alleviate the risk that the stakeholders take when they need to use their passphrase to provide signatures, especially when the addresses that they control hold large amounts of bitcoins.
 +
Additionally, it's preferred that the client application would behave automatically instead of prompting for passphrase at every signatures block.
 +
 +
We basically want a digital signatures scheme in which the keygen generates a triple (privkey1,privkey2,pubkey0) where privkey1 and privkey2 are unrelated to each other, you can sign either with privkey1 or with privkey2, and verify the resulting signature with pubkey0. It'd be used for PoS by using privkey1 to do actual txns and using privkey2 only for providing the PoS signatures to the signatures blocks. This means that if privkey2 gets stolen then it doesn't amount to much, you can transfer your bitcoins to another address and re-generate a new privkey2 for it, so it's ok to store privkey2 in the clear.
 +
 +
We cannot implement this scheme directly with ECDSA, but we can do something that's pretty close: simply by having two pairs (privkey1,pubkey1) and (privkey2,pubkey2) and linking between them, e.g. by signing with privkey1 a message that says that pubkey2 is the public key of your 2nd pair, and from then on you can start using privkey2 to provide the PoS signatures.
 +
 +
What it would mean for the blockchain is that when you provide a STAKEMSG, there would be an additional field that you can include in it, and this field would contain pubkey2, meaning that starting from the next checkpoint block you are allowed to use privkey2 in order to provide signatures for the address that's controlled by privkey1. The protocol rule would be that only first pubkey2 that the stakeholder provides is respected, meaning the nodes should scan for pubkey2 starting at POSGEN.
 +
 +
Note: the pubkey that would be extracted from subsequent STAKEMSGs is pubkey2 rather than pubkey1, therefore in order to tell how many bitcoins are controlled by those STAKEMSGs it'd required to scan for the first STAKEMSG that linked pubkey2 to pubkey1, and then deduce how many bitcoins pubkey1 controls. It might be better to store more data in every STAKEMSG, such as field that specifies in which block pubkey1 and pubkey2 were linked (and then the protocol rule would be that only this particular linkage should be respected).
 +
 +
Note: if the pubkey2 field of STAKEMSG is empty then the signature field of STAKEMSG signed just B->hash, and if the pubkey2 field of STAKEMSG isn't empty then the signature field of STAKEMSG signed "B->hash + pubkey2".
 +
 +
With ECDSA signatures are 512 bits and compressed pubkeys are 258 bits, so it's not so bad because the STAKEMSGs with the extra pubkey2 field would be infrequent. In fact, we can save more space by defining the protocol so that only hash(pubkey2) is put in the extra field, because of the feature of ECDSA that you can extract pubkeys from signatures. This means that the extra field can be just (say) 128 bits hash, but more computing power will be needed to verify the signatures blocks, so maybe the client app should cache this data (security risk?).
 +
 +
This means that you wouldn't need to enter your passphrase in order to provide PoS signatures, so that the client app can work automatically, as preferred.

Revision as of 13:11, 15 August 2012

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.1     // proportion of the reward at each PoS checkpoint that goes to stake holders
  • 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 any branch that it saw (preferably a branch whose signatures block was signed with the most bitcoins so far), and it 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). There would be an optional txn fee that the stakeholders can pay by attaching this fee to their STAKEMSGs, in order to give incentive to the miners to include STAKEMSGs in the blocks.

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) goes to the miner who generated the block

Note:

  • In (i) we divide proportionally among stakeholders according to the amount of bitcoins that they controlled at block B->count

An address must have at least STAKECUTOFF bitcoins at block B->count in order to to provide a STAKEMSG. This means for example that if an address with more than STAKECUTOFF bitcoins has transferred all of its bitcoin the an empty address between B->count and (B->count)+SIGBLOCK then this address can still provide a STAKEMSG after this txn, but the empty address cannot because at block B->count it had 0 bitcoins.

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 more than N*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.

Client behavior (+more protocol rules)

We wish to alleviate the risk that the stakeholders take when they need to use their passphrase to provide signatures, especially when the addresses that they control hold large amounts of bitcoins. Additionally, it's preferred that the client application would behave automatically instead of prompting for passphrase at every signatures block.

We basically want a digital signatures scheme in which the keygen generates a triple (privkey1,privkey2,pubkey0) where privkey1 and privkey2 are unrelated to each other, you can sign either with privkey1 or with privkey2, and verify the resulting signature with pubkey0. It'd be used for PoS by using privkey1 to do actual txns and using privkey2 only for providing the PoS signatures to the signatures blocks. This means that if privkey2 gets stolen then it doesn't amount to much, you can transfer your bitcoins to another address and re-generate a new privkey2 for it, so it's ok to store privkey2 in the clear.

We cannot implement this scheme directly with ECDSA, but we can do something that's pretty close: simply by having two pairs (privkey1,pubkey1) and (privkey2,pubkey2) and linking between them, e.g. by signing with privkey1 a message that says that pubkey2 is the public key of your 2nd pair, and from then on you can start using privkey2 to provide the PoS signatures.

What it would mean for the blockchain is that when you provide a STAKEMSG, there would be an additional field that you can include in it, and this field would contain pubkey2, meaning that starting from the next checkpoint block you are allowed to use privkey2 in order to provide signatures for the address that's controlled by privkey1. The protocol rule would be that only first pubkey2 that the stakeholder provides is respected, meaning the nodes should scan for pubkey2 starting at POSGEN.

Note: the pubkey that would be extracted from subsequent STAKEMSGs is pubkey2 rather than pubkey1, therefore in order to tell how many bitcoins are controlled by those STAKEMSGs it'd required to scan for the first STAKEMSG that linked pubkey2 to pubkey1, and then deduce how many bitcoins pubkey1 controls. It might be better to store more data in every STAKEMSG, such as field that specifies in which block pubkey1 and pubkey2 were linked (and then the protocol rule would be that only this particular linkage should be respected).

Note: if the pubkey2 field of STAKEMSG is empty then the signature field of STAKEMSG signed just B->hash, and if the pubkey2 field of STAKEMSG isn't empty then the signature field of STAKEMSG signed "B->hash + pubkey2".

With ECDSA signatures are 512 bits and compressed pubkeys are 258 bits, so it's not so bad because the STAKEMSGs with the extra pubkey2 field would be infrequent. In fact, we can save more space by defining the protocol so that only hash(pubkey2) is put in the extra field, because of the feature of ECDSA that you can extract pubkeys from signatures. This means that the extra field can be just (say) 128 bits hash, but more computing power will be needed to verify the signatures blocks, so maybe the client app should cache this data (security risk?).

This means that you wouldn't need to enter your passphrase in order to provide PoS signatures, so that the client app can work automatically, as preferred.