Topic: Help: The two wallet system (Read 2928 times)

Hmm... that just gave me an idea for dealing with some of the problems of encrypting private keys. Divide private keys into two pools, encrypted and cleartext. Allow users to move keys from one pool to the other by entering an amount, and attempting to approximate that amount with the coins owned by one or more private keys.

Think it could work?

edit... Fleshed out idea, cross posted from github/issues:

Suppose we encrypt keys with the public key of a separate private key. That private key is encrypted with a symmetric algorithm, whose key is derived from the passphrase. I believe this is how GnuPG works. When we store this encrypted key in the wallet, we also store a reference to the associated private key. (Or, perhaps have it elsewhere on the file system... usb drive? smart card? keyring?) With this functionality, we could prompt the user for a password once and decrypt multiple keys. It also means that a wallet could be separated into virtual partitions with different encryption keys. I think it would allow a smooth transition, but would it be backwards compatible?[1]

Here's the way I imagine interacting with this. I would keep a small amount of bitcoin in the clear. This allows me to easily spend the small amount while assuring I won't lose much if my device is compromised (good for mobile devices). I can easily encrypt/decrypt keys by entering a target amount to "transfer". The actual amount is determined by picking keys with transactions (outputs?) summing to approximately the target[2]. In order to spend more than is in the clear, I must enter one (or more) passphrases, but the rest is automated.

[1]Can the structure of the wallet be modified for encrypted keys and a reference to the encrypting private key without causing a breaking change?

[2]You can't split the output of a transaction without writing to the block chain, right?

It's just terminology but people probably already have two or more "wallets" that they use differently. It just clarifies that the safe is the place where you can put large amounts safely and the wallet is where you can put small amounts that are easier to access and don't have as many overheads, back-ups, off-site copies, etc.

If you had one wallet with BTC 50,000 in it you are going to treat that a lot more carefully than the wallet with BTC 50 in it, no? Just easier to call one the safe and the other the wallet ... take it or leave it, just trying to put some words with concepts that already in practice.

Wallet, safe, vault ... straightforward translation from physical specie.

Entering a password every time you want to send coins (or pulling out your... dongle... err, that didn't come out right, uhh, fetching your one-time-password-generating-device) might be annoying enough that withdrawing 50 or 100 bitcoins that you can spend with minimal hassle would be a nice feature.

Why? It's all the same thing, a group of private keys. If it needs to be more secure, require a password, biometric access, whatever. There's no good reason I can think of to distinguish between one keystore and another.

Eventually I would like to see some bitcoin software featuring a SAFE and WALLET system.

Obviously, the safe stays at home on a system that has significantly higher security specs than the wallet.

By the same token, safes are designed to be harder to get into, even by the user, but hold more and are more rigourously backed-up.
Of the pair, the wallets are easy to open but only hold small amounts and can easily be moved around mobile devices.

Further out, there could be a VAULT for corporate holdings, or a vault for collective holdings held by a trusted security center for people who don't feel confident guarding their own safes.

Your wallet contains keys for all of the addresses you've received bitcoin to, plus 100 that haven't been used. Your backup is good until you've used all 100 extra keys.

The key pool is not a limit, it’s just that 100 addresses already exist. You generate them in the client, but technically they are already there, so the first 100 will always stay the same no matter which backup you’re using.

Hold on, if at any point you only have those 100 keypairs, how is money retained from key 3 to key 304 if each is signed by a given keypair?

The limits will be increased once the network is mature enough to handle it.

thank you very much, sir.
i did not read the c/cpp sources of the bitcoin project. in my vildest dreams the number of transactions per hour was more or less unlimited (or at least 5 digits). i like to learn new stuff (even if it's marked with blood of dead concepts)

The fees are specified in GetMinFee in main.h.

27k of the block is available for free transactions, 250k is available for normal 0.01/k transactions, and 500k is available for higher-paid transactions (required fees are scaled after 250k). These limits overlap. Mainline Bitcoin therefore only fills the block to 500k, and blocks over 1000k will be rejected.

I used an average transaction size of 250 bytes, which is close to the real average of 254.

wat? could you, please, provide me with a pointer to specs how the limits are imposed on the network?
is it the size limit of a block?

He's talking about the faucet. The network will accept ~650 free transactions per hour, and ~6000 transactions at the normal paid rate per hour.

You're talking about the BTC faucet, not the Bitcoin network as a whole, right? If that's all that Bitcoin can process, there's a serious bottleneck right there that could stop early adoption.

if your client has downloaded all blocks in the chain, you would see any incoming payment instantly.
it would have 0 confirmations but you would see the payment as broadcasted in the network and waiting for confirmation.

as for why you do not see it, 'gavin' wrote somewhere that there's a limit of 120 transactions in 2 hours. if you were waiting, you were probably processed in the "next" round. post your address here or PM me and i send you two cents so that you can fool around (p.ex. send one of them to a mybitcoin like web wallet and send it back to you to see the speed of transactions)

the waiting for confirmation does not meat it did not happen.

Bitcoin Block Explorer also has an RSS feature, so you can subscribe to the RSS feed of your savings address to make sure the funds are being delivered.

There's no need to backup your savings wallet more than once if you're using just one address in it and not making any sends. The problem is when new addresses are created. Counter-intuitively, the most common time when an address is created is when you send coins. They are not created when you receive coins. So you should back up after you make 100 sends from your savings account.

[/quote]
It takes one block to be produced (approximately 10 minutes, but that can vary a lot) and after that, you should be able to see the transaction in your client.
[/quote]

Wow, that is one robust system...

Not that I worry, I assume this has all been figured out, but what happens to unconfirmed coins that are sent? 

The reason I understood why people would say to backup your wallet after every transaction is because of address creation. If you have an old version of your wallet backed up, and then create a new address, receive 50 BTC to that address from somebody, and then your hard drive dies a few days later without another backup, the wallet.dat that you have backed up does not have the keys for that address you created. Your 50 BTC would be lost!

If I'm not right, please correct me.

Well, actually you don’t even need to ever backup if you only use a single address in your bank, but that would make it less anonymous. As I said, the wallet stores your private keys to the addresses. The keypool has 100 addresses, so that means that if you use 100 addresses, you will have to backup. I would just backup after each transaction to make sure, I guess.

It takes one block to be produced (approximately 10 minutes, but that can vary a lot) and after that, you should be able to see the transaction in your client.

First of all, thanks so much for the tips, this community is great.

But why is it I don't have to update the savings account at all if I just send to it, but as you guys say, I need to backup after every transaction?

Also, how long does it take to confirm the .05 coins I got from the appspot program by gavin?  If what I understand is right, the transaction needs to be verified by the hashes of more clients?   (8 connections is what I max out at if that has any bearing)