ppcoin offline coinstake creation

[Jutarul]

this is a reminder that we need an air gaped solution to create coinstake. In the long run it's a liability to have the private keys on the validation nodes.

From my current understanding this would work:

1) offline: generate coinstake transaction candidates (CSTC) by sequentially changing the time stamp from now up to a future time (e.g. a year from now)  and save them on disk.

2) transfer

3) online: ppcoind reads CSTCs from file and filters them by applying a sliding window over the timestamp. If a CSTC meets the target specs it gets consumed and the corresponding stake cannot longer be used.

rinse and repeat every 1-2 months or so (to bring consumed stake back online).

Ideally this would be a feature of ppcoin in the future, but maybe someone already hacked something like this? If so please post here.

[1714838726]

1714838726

[1714838726]

1714838726

[Sunny King]

It's something to consider for the long term but probably lot of work involved.

Dunno if all these new bitcoin transaction types may help somewhere also.

[Jutarul]

It's something to consider for the long term but probably lot of work involved.

I don't think so. If I find the time I may do it myself. I expect about 2-3 hours of programming required.

Dunno if all these new bitcoin transaction types may help somewhere also.

Unlikely. When the coinstake is created the full information for a valid signature has to be available. When coinstake is created on the validation nodes, this necessarily means that the information has to be on the node.

The only solution is to split creation and consumption to different machines.

[AndyRossy]

It's something to consider for the long term but probably lot of work involved.

I don't think so. If I find the time I may do it myself. I expect about 2-3 hours of programming required.

Lets get some discussion/consensus going either way. 

I think it's definately something that needs discussing though.

[Jutarul]

I think the critical question is how much information is needed to generate the input for the coinstake hash. The Hash is computed the following way:

HASH( nBits + block.nTime + (txindex.pos.nTxPos - txindex.pos.nBlockPos) + pcoin.first->nTime + pcoin.second + txNew.nTime )

1) nBits: The difficulty recorded in the last valid block.
2) block.nTime: The timestamp of block containing the transaction referenced by stake
3) (txindex.pos.nTxPos - txindex.pos.nBlockPos): Relative byte position of the transaction referenced by the stake.
4) pcoin.first->nTime: The timestamp of the transaction referenced by the stake
5) pcoin.second: The output number in the transaction referenced by the stake
6) txNew.nTime: the timestamp of the coinstake transaction.

I didn't find more documentation of what the specific fields mean. Maybe Sunny can help with explaining them.

However, the offline creation of a coinstake transaction does NOT require you to meet the HASH target in advance. It just requires you to sign a coinstake transaction which is dated correctly.

Thus the only thing which needs permutation in advance is txNew.nTime, and the coinstake reward needs to be calculated correctly for the "anticipated" time.

The validation node will still have to test coinstake candidates against the current state of the network. (nBits)

[Sunny King]

It's not just the coinstake, block needs to be signed as well.

One possibility is that some special transaction type can be introduced and there will be a separation of spending key and stake key. Stake key can only 'refresh' the coin by moving the coin to the same address (spending key). So stake key is online to mint block and spending key is in cold storage.

[cunicula]

One possibility is that some special transaction type can be introduced and there will be a separation of spending key and stake key. Stake key can only 'refresh' the coin by moving the coin to the same address (spending key). So stake key is online to mint block and spending key is in cold storage.

I think the separation of the two keys is the way to do this.

[Jutarul]

It's not just the coinstake, block needs to be signed as well.

I didn't notice that. That certainly complicates things.
Sorry for my ignorance - where does this block signing take place? All I see is a SignSignature of the coinstake transaction under CreateCoinStake(...). Found it: key.Sign(GetHash(), vchBlockSig);

Would you be so kind to explain why the block needs to be signed as well? It seems to be a feature of ppcoin, because I don't see it in bitcoin.

One possibility is that some special transaction type can be introduced and there will be a separation of spending key and stake key. Stake key can only 'refresh' the coin by moving the coin to the same address (spending key). So stake key is online to mint block and spending key is in cold storage.

That sounds like a good idea. That transaction type would be interesting for more than one reasons. The way I understand it, it's a restrictive branch-transaction type, where the choice of the key determines which PPC address gets the coins. (The only risk I see there is that an entity can steal "stake-mining power" and the owner may not be easily aware of that. The simple solution would be to move the coins to a new PPC address once in a while.)
However, as far as I understand the scrypting framework, the scriptPubKey only unlocks the coins. It cannot control the downstream coin flow. Thus it's not simply a new transaction type. It would have to be hardcoded into the client behavior. Am I wrong?

[Jutarul]

Would you be so kind to explain why the block needs to be signed as well? It seems to be a feature of ppcoin, because I don't see it in bitcoin.

(bump)

[Sunny King]

Would you be so kind to explain why the block needs to be signed as well? It seems to be a feature of ppcoin, because I don't see it in bitcoin.

(bump)

This was explained in the design paper, if block is not signed an attacker can reuse other blocks' coinstake in his own block.

[Jutarul]

This was explained in the design paper, if block is not signed an attacker can reuse other blocks' coinstake in his own block.

I see. Even though the attacker would not get the benefit of the POS reward, he could utilize it as mining power. Is there a reason why the key for the coinstake transaction has to be the same as the key for block signing?

[makomk]

This was explained in the design paper, if block is not signed an attacker can reuse other blocks' coinstake in his own block.

Yeah, Solidcoin 2.0 made this mistake when implementing their trusted blocks.

[Sunny King]

This was explained in the design paper, if block is not signed an attacker can reuse other blocks' coinstake in his own block.

I see. Even though the attacker would not get the benefit of the POS reward, he could utilize it as mining power. Is there a reason why the key for the coinstake transaction has to be the same as the key for block signing?

The signing key must belong to the stake owner. If in the future a separation of spending key and stake key can be implemented then block can be signed by stake owner's stake key.

[AndyRossy]

This was explained in the design paper, if block is not signed an attacker can reuse other blocks' coinstake in his own block.

I see. Even though the attacker would not get the benefit of the POS reward, he could utilize it as mining power. Is there a reason why the key for the coinstake transaction has to be the same as the key for block signing?

The signing key must belong to the stake owner. If in the future a separation of spending key and stake key can be implemented then block can be signed by stake owner's stake key.

Right, if we did this, how would this negate the positive effects of PoS vs a 51% attack?

[Sunny King]

Right, if we did this, how would this negate the positive effects of PoS vs a 51% attack?

There shouldn't be any negative effect on proof-of-stake. Users would have the additional option to leave only the stake key online and move all other private keys to a cold-storage wallet. This would greatly reduce the risk of losing coins to hackers thus encourage more users to participate in stake generation. So it should help strengthen proof-of-stake.

Although this is just an idea at the moment and lot of work is probably needed to come up with a concrete design proposal, including maybe a full review of bitcoin's scripting engine which I haven't done before.

[cunicula]

I don't see any downside to temporary key separation either. Just make sure it isn't permanent. The stake key should be "refreshed" whenever the send key is used. You don't want people to be able to sell their stake keys to others.

[Jutarul]

(bump)

Has there been any development in the direction of a more secure way to generate proof-of-stake blocks, i.e. remove private keys for stake from the mining computer?

[Sunny King]

(bump)

Has there been any development in the direction of a more secure way to generate proof-of-stake blocks, i.e. remove private keys for stake from the mining computer?

Not recently. For me I probably would revisit this topic after new year. If some of you are good with bitcoin tx scripts and various advanced transactions feel free to make some proposals as to how stake key can be managed separately from spend key.

[Jutarul]

(bump)

Has there been any development in the direction of a more secure way to generate proof-of-stake blocks, i.e. remove private keys for stake from the mining computer?

Not recently. For me I probably would revisit this topic after new year. If some of you are good with bitcoin tx scripts and various advanced transactions feel free to make some proposals as to how stake key can be managed separately from spend key.

I'd gladly contribute to this development. However, my schedule is packed with other stuff right now, so I don't see myself working on this issue before December.

Maybe we should organize a bounty for this? I'd be willing to pledge a few PPC for a decent proposal, which provides the basic feature of key-mining separation. Even a work-around would be acceptable. Target for the bounty should be $500-$1000? Condition is that the person provides the necessary instructions and/or code to implement the feature and that the proposal actually works as intended.

[cunicula]

Maybe we should organize a bounty for this?

I think you need to consider this 'feature' more carefully before raising a bounty. It may be a serious 'bug' if implemented poorly.

Giving away a copy of the stake signing key has no risk for the user whatsoever, but the signing keys are valuable to an attacker. Therefore, an attacker could purchase up all the signing keys really
cheap and attack the network. The attack could not be stopped. (attacker could refuse to allow anyone to include txns that revoke the sign key). This must be avoided. Offline stake creation also seems like a bad idea for similar reasons.

Stake signing should not be a risk-free process. Risk-free private keys should not exist.

A better solution is to make two keys: one high-functionality high-risk key, one low-functionality low-risk key.

a) The high risk key can do anything. The high risk key can also move all the coins at once, invalidating the low risk key.

b) The low risk private key can spend 0.01% of its balance per block. Enforce this as follows. Every txn signed by the low risk key must send at least 10000 satoshis to its own public key address for every 1 satoshi sent to another address or used as a txn fee. [this is a block validity rule; txns that don't obey this cannot be included in blocks] This key can then be depleted at a maximum rate of about 1.5% per day.The low risk key can also provide proof-of-stake.  You can expose this key to the network at low risk. You might share it with a well-trusted party. You wouldn't share this key with an anonymous individual however.  

Each wallet should list two types of balances: Spending and saving

1) Savings wallets are unencytped. Savings wallets have low risk private keys online and unencrypted and high risk private keys in cold storage. Savings wallets try to provide PoS.

2) Spending wallets are optionally encrypted. They should have both the low risk private key and the high risk private key online. These wallets cannot provide PoS if they are encrypted.

Users can shift coins back and forth as needed. This is a good improvement for three reasons.

1) It makes stake provision safer

2) It makes the currency safer to use in general (i.e. now it would be like you can call the credit company and report your private key stolen. Think how many unlucky bitcoin users have wanted to do this at some point.)

3) Convenience is maintained because the spending wallet still provides the traditional functionality.