Topic: Insecure local private keys problem definition (and brainstorming) (Read 1167 times)

I don't know how novel this idea is, but wallet-less miners are possible.

No, they don't. You can have a dedicated piece of hardware not connected to any network for signing.

Then if you want to transact you create a partial (unsigned) transaction on you main computer connected to network, write transaction onto some storage medium, then go to your dedicated signing hardware, plug this storage medium in, review transaction details, sign it and move signed transaction back to your main computer to broadcast it.

It is crucial to understand that

1. Transaction can be broadcast from any node.
2. To make a transaction you only need a keypair and input details, but you don't need to be connected to network.

Also it is possible to make transactions which require more than one signature.

Yes, absolutely. Walk your transactions to the machine that has your private key, a machine which is not connected to the network, then walk the signed transactions to the machine that has a network connection. It would not be difficult to add commands to the client to import and export transactions. No machine connected to the network need ever have your private key.

If I held a large number of BitCoins, this is how I'd protect my savings account.

You have probably seen the topics on wallet encryption and brainstorming?

Split private keys
[PULL] Wallet Private Key Encryption
Coinsplit

PS: ECDSA is a signing only algorithm, you can't use it for encryption.

If I'm understanding this correctly, the philosophy behind the bitcoin network protocol has been to concentrate the effort in securing network comms. (transaction sends, block transmission, etc) and securing the block chain record (hashing) but leave securing the client nodes private keys up to the end users. However, I think this overlooks the fact that for the send tx. to occur the client has to move around the unencrypted private keys on network connected hardware.

In this sense, we can consider the network connected hardware of the clients to be part of the network and maybe should be treating it as such. The alternative is to tend towards a two-tiered system where web-wallets, exchanges, merchants, etc who need to have clients connected 24/7 will bear the brunt of maintaining network stability, operating with 'live' wallets, while a majority of users who will only briefly connect clients intermittently. Obviously, this will lead towards a more centralised client-server relationship that seems to go counter to the ethos of the project.

The problem then:

unencrypted private keys must reside and move around on the client's network connected hardware, at some point, for signing of the send transactions to occur and thus any network connected hardware forms part of the bitcoin network at that point in time.

In this light, perhaps solutions to consider could involve encrypting the private keys with the same strength of the signing of the send tx themselves (ECDSA) operating under the assumption that the clients machines, PC's, servers, etc, are essentially part of the untrusted network layer. As a brainstorm, is it possible to come up with a cryptological scheme whereby the private keys never need be decrypted on the client machine yet can still perform the signing?

Anything else will probably lead to a situation where the long term stable network effectively ends at those nodes that are capable of securing private keys on network connected hardware. Possibly limiting widespread adoption.