Bitcoin Redundancy For Security

[genjix]

Hey,

I'm writing a proposal and talking about security. So far my weak point is that one computer holds all the Bitcoins.

Is there a way to have an online wallet spread over 8 computers and requiring confirmation from all 8 parties to carry out a command?

The closest idea I got was using GPG to encrypt different parts of the wallet and then one node reconstructs the wallet, does the command and re-splits it up amongst the other nodes.

[1714146829]

1714146829

[1714146829]

1714146829

[1714146829]

1714146829

[1714146829]

1714146829

[genjix]

And if one node that has the reconstructed wallet goes rogue and decides to send all the money to themselves- there's nothing you can do.

[davout]

you could also schedule something like
 - ensure you have a sufficient keypool for your needs
 - every day/hour/whatever compress and encrypt the wallet,
 - send it to your gmail, NAS, whatever

[grondilu]

Hey,

I'm writing a proposal and talking about security. So far my weak point is that one computer holds all the Bitcoins.

Is there a way to have an online wallet spread over 8 computers and requiring confirmation from all 8 parties to carry out a command?

The closest idea I got was using GPG to encrypt different parts of the wallet and then one node reconstructs the wallet, does the command and re-splits it up amongst the other nodes.

Splitting your wallet is not a bad idea.  Just be carefull to leave more than one instance of each part, though.

Actually if you use N computers, then I think you should make N copies for each Nth part of your file, otherwise you increase the risk of loosing everything in case one computer is down.  But you need to study it more seriously if you want an exact probabilistic approach to this.

Anyway, spliting a file in several parts is easy in unix.  Just use the 'split' command.

[genjix]

What I'm asking though, is that with this scheme you're trusting ONE person.

The one person who re-assembles the wallet and does the transaction.

What if he sent all the funds to himself?

How can we have all 8 nodes together confirm to send BTC with each other's consent?

[grondilu]

What I'm asking though, is that with this scheme you're trusting ONE person.

I don't quite follow you.  You should trust nobody.

You don't intend to store your wallet without encrypting it, do you ?

[theymos]

Script supports creating transactions that can only be redeemed with the signatures of several public keys. So if someone wants to send one of these coins, they would have to get signatures from all of the other "owners".

Implementing this in a convenient way would be tough, and it would be blocked by IsStandard.

[genjix]

Implementing this in a convenient way would be tough, and it would be blocked by IsStandard.

Why does IsStandard block this? It's a great idea. If a wallet requires the keys of several people then it's possible to have distributed security instead of placing your trust in one source.

[theymos]

Why does IsStandard block this?

IsStandard blocks everything that is not standard...

[davout]

IsStandard blocks everything that is not standard...

It's a client limitation and IMO lots of miners will remove it eventually.

[Gavin Andresen]

Implementing this in a convenient way would be tough, and it would be blocked by IsStandard.

No, implementing it would be easy.  Implement it (don't forget the UI), test it on the test network (where it is pretty trivial to get non-IsStandard stuff into blocks), and then lobby for a new 'standard' transaction type.

theymos, please stop acting like the current IsStandard test is set in stone. It is not, and, as Satoshi said, new versions of the client are rapidly adopted by a majority of the network, so introducing a new transaction type will not be a big deal.

[genjix]

Thank you. This is great.

[theymos]

No, implementing it would be easy.

I'm not saying it's difficult because it would currently be blocked by IsStandard. You'd need new wallet code, new UI code, and some way to sign a transaction that hasn't already been published (probably new network protocol extensions).

IsStandard is just one of many hurdles. I'm particularly irritated about IsStandard because it requires developers to appeal to a central authority.