Author

Topic: Proof of Stake with Entropy loss as signature cost (Read 2498 times)

full member
Activity: 214
Merit: 101
Each address that participates in signing will have a deterministic secret S (it has to be deterministic to make their sharing verifiable) known only to them (i.e. the initial secret state could just be the SHA256 of an ECDSA signature over the genesis block),

ECDSA is not deterministic (and can't be made deterministic in a publicly verifiable way). Also I'm not sure what the relationship between determinism and verifiability is? Also in your example can you clarify which key is used for signing, and how this is determined. (If the key does not need to be deterministic, you can us a unique signature scheme; there are efficient ones out there.)

Quote
all the algorithmic steps are normal, except instead of distributing the secret among a number of holders, they will include a point pair (Xi, Yi) on each Block_i which they sign, where Xi is something publicly known such as the block-header hash of the block, and Yi is computed. Note, Shamir's Seceret Sharing has no mechanism for cheater resistance,

Can you clarify "cheater resistance"? Do you mean collusion, parties changing the secret after the fact, parties publishing invalid shares, ... ? What is the specific attack you are trying to block?

Quote
but with cryptocurrencies identity is already established with ECDSA,

Can you clarify this? ECDSA is a signature scheme and can't be used directly to establish identity.

Quote
since PoS reward does not need to be immediate (see below), it can be easily verified if said signer cheated when providing Xi, Yi pairs.

"immediate" is a time-related word. Can you argue that you are not begging the question by assuming a consensus time-ordering? (In this case I think you are not, but I'm reading more than you've written so I want to make sure you're on the same page.)

Quote
I suggest re-adjusting block reward to a method, Let's call it Sign-Accumulate-Redeem. Fees from Block Processing will be collected and not returned instantly. For a given stake holder address after they have signed (n-1) number of blocks, they can claim their rewards, by referencing the number of each block in which they have signed, and also revealing their secret S . If S has already been revealed they cannot claim anything.

How is this different from having them sign (n-1) blocks with the same key, and have a consensus rule that this is the condition for reward distribution?


As mentioned the idea is to prevent double signing - simple enough. In practice it's difficult because in i.e. Proof of Work there is an external input cost (electricity) which is the 'cost' of signing if you will, whereas with Proof of Stake there is no cost, since blockchain's are not conscious of 'each other' it's impossible to tell from blockchain A that someone is also signing blocks in blockchain B.
So the question is how do we limit someone's ability to make multiple signatures? My suggestion for doing it is having them give away information about deterministic secret S (known only to them) each time they sign. Suppose a hypothetical PoS implementation where one can collect a block reward after they have had the opportunity to sign 100 blocks. There aren't any limits to how or which blocks they sign, but if they sign one more block past 100 (or whatefer N is) would enable anyone to calculate S by polynomial interpolation.
"Cheater resistance" refers to the idea that in Shamir's secret sharing the dealer and the holders are assumed to be honest. There are no holders in this implementation (or everyone with a blockchain copy if want) and the dealer would be the signer. Cheating would be if for example the signer used S1 for Blockchain A and S2 for Blockchain B, they would still generate (Xi, Yi) pairs that would look correct, but interpolation using a combination of those points would not yield S correctly. Since signer or stakeholder is also signing with ECDSA when signing a block and giving a point pair, when they reveal S (or point N+1 would work as well), and reference the blocks which they signed to collect their block reward (fees), anyone can verify with interpolation that they provided valid points in all the referenced blocks.
full member
Activity: 179
Merit: 151
-
Each address that participates in signing will have a deterministic secret S (it has to be deterministic to make their sharing verifiable) known only to them (i.e. the initial secret state could just be the SHA256 of an ECDSA signature over the genesis block),

ECDSA is not deterministic (and can't be made deterministic in a publicly verifiable way). Also I'm not sure what the relationship between determinism and verifiability is? Also in your example can you clarify which key is used for signing, and how this is determined. (If the key does not need to be deterministic, you can us a unique signature scheme; there are efficient ones out there.)

Quote
all the algorithmic steps are normal, except instead of distributing the secret among a number of holders, they will include a point pair (Xi, Yi) on each Block_i which they sign, where Xi is something publicly known such as the block-header hash of the block, and Yi is computed. Note, Shamir's Seceret Sharing has no mechanism for cheater resistance,

Can you clarify "cheater resistance"? Do you mean collusion, parties changing the secret after the fact, parties publishing invalid shares, ... ? What is the specific attack you are trying to block?

Quote
but with cryptocurrencies identity is already established with ECDSA,

Can you clarify this? ECDSA is a signature scheme and can't be used directly to establish identity.

Quote
since PoS reward does not need to be immediate (see below), it can be easily verified if said signer cheated when providing Xi, Yi pairs.

"immediate" is a time-related word. Can you argue that you are not begging the question by assuming a consensus time-ordering? (In this case I think you are not, but I'm reading more than you've written so I want to make sure you're on the same page.)

Quote
I suggest re-adjusting block reward to a method, Let's call it Sign-Accumulate-Redeem. Fees from Block Processing will be collected and not returned instantly. For a given stake holder address after they have signed (n-1) number of blocks, they can claim their rewards, by referencing the number of each block in which they have signed, and also revealing their secret S . If S has already been revealed they cannot claim anything.

How is this different from having them sign (n-1) blocks with the same key, and have a consensus rule that this is the condition for reward distribution?
full member
Activity: 214
Merit: 101
(Eliminating Nothing-is-at-Stake using Shamir's Secret Sharing)

Each address that participates in signing will have a deterministic secret S (it has to be deterministic to make their sharing verifiable) known only to them (i.e. the initial secret state could just be the SHA256 of an ECDSA signature over the genesis block), all the algorithmic steps are normal, except instead of distributing the secret among a number of holders, they will include a point pair (Xi, Yi) on each Block_i which they sign, where Xi is something publicly known such as the block-header hash of the block, and Yi is computed. Note, Shamir's Seceret Sharing has no mechanism for cheater resistance, but with cryptocurrencies identity is already established with ECDSA, since PoS reward does not need to be immediate (see below), it can be easily verified if said signer cheated when providing Xi, Yi pairs.   

I suggest re-adjusting block reward to a method, Let's call it Sign-Accumulate-Redeem. Fees from Block Processing will be collected and not returned instantly. For a given stake holder address after they have signed (n-1) number of blocks, they can claim their rewards, by referencing the number of each block in which they have signed, and also revealing their secret S . If S has already been revealed they cannot claim anything.
Reward calculation can just be something like sum (stake/total_signing_stake * (coin_days modifier) * (fees_collected in block)).

Jump to: