Quote from: cunicula on August 18, 2012, 03:39:59 PM

The security issue raised by large balance hot wallets could be dealt with as follows:

1) Create special account used for signing blocks
account restricted to two valid functions: 1) Sign blocks using coins in special account
2) Release coins in special account to user-specified normal account (specified address set permanently when special account is created)
2) Special account is held in hot wallet.
3) User-specified normal account is held offline.

Good idea. I've described a similar suggestion for PoS protocol design outline on MeniRosendfeld's wiki talkpage at https://en.bitcoin.it/wiki/User_talk:Holy-Fire, so I'll also quote the relevant part here:

Quote

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 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 we store in every STAKEMSG an additional field that specifies the height of B->count relative to the block in which pubkey1 and pubkey2 were linked (and then the protocol rule would be that only this particular linkage should be respected). If we use e.g. 3 bytes for the relative height field, then privkey1 will be needed to create a new linkage block after about 320 years (assuming 10min blocks).

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.

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.

See the rest at https://en.bitcoin.it/wiki/User_talk:Holy-Fire#Proof_of_Stake_design_outline

You said "specified address set permanently when special account is created". In case it's a protocol that extends the existing Bitcoin protocol, the linkage between this special address and its corresponding locked normal address will have to be put in the blockchain, so whenever the special address wishes to transfer some of its coins to the locked normal address, all the nodes must look at the old block where the linkage was made in order to verify it. Therefore I'm not sure whether your suggestion is more efficient than my suggestion. There could also be disadvantages from the user's standpoint, because he has to transfer his coins before he can spend them.

Regarding Gavin's DoS concerns, in the simple PoS design outline that I described it's handled by hardcoded cutoff constant, meaning that an address cannot provide a PoS signature if it holds less coins than the cutoff amount. This is need also in order to prevent bloat in the blockchain, otherwise anyone with 1 satoshi could try to provide PoS signatures...