Post
Topic
Board Project Development
Re: [Idea] The Bitcoin Banking Project
by
Carlton Banks
on 01/01/2014, 17:27:03 UTC
A public derivation of the masterkey for generating addresses is much better than P2SH enforced.

I respectfully disagree.   If the server you use has the only copy necessary to spend your money then you are in an entirely different realm of banking.  My solution proposes that you are in full control of your money and the "bank" is only there to provide some convenience.
Huh!!! Public derivation

D'oh.  You're right!  You're doing Bip32 public key derivation using a single key.  For what it's worth, I'm the author of the javascript bip32 implementation at https://github.com/sarchar/brainwallet.github.com/blob/bip32gen/js/bip32.js

The point of multisignature (whether it's p2sh or not) was to provide some backup in case of lost keys.

I think that's the possible awkward part.

It's not possible (or not that I understand) for the client to know what adapted version of the server-side source code is being used. If you have a bad actor running the server, they know how much their HNW clients have in their accounts. This could motivate them to expend alternative (real world) resources to ensure that the paper backup or the wallet seed aren't available to the client (somehow). If the bad actor server can do this in a way that does not implicate their complicity, could they extort money from the client by pre-implementing server side code that refuses to derive a new address chain, or that refuses to sign transactions to access his lost funds?

And, (server bad actors aside) what if the client loses the paper wallet and his seed? With current clients, you've still got your 1 of 1 wallet file, and you may still remember the encryption password for that. When you introduce a third party backup private key and enforce 2 of 3 signatures, even if the wallet file still exists and the encrypting password are known, you can't sign tx's from the wallet. It would be interesting if the multisig keys scheme could be modified so that not all signing keys are equal, although I get the feeling this depends on the way it's implemented upstream at the bitcoin protocol level. The seed could perhaps have 1 of 3 a signing quorum, and the paper wallet and server key could have 2 of 3.