New Wallet Format

[justusranvier]

If I understand correctly the new wallet format is primarily intended to support BIP 32, but will it also support non-deterministic or even "single-key" wallets?

The reason I ask is because I have imported my blockchain.info private key into an Armory wallet so that my ability to spend those funds is not limited to blockchain.info's uptime. In order to do this I had to make a regular deterministic wallet and manually add the key (which is fine), but I never had the option to dispense with the unneeded deterministic keys. It also means that any time I use Armory to initiate a transaction instead of the web client I must be careful to manually specify the change address to avoid sending it to the deterministic addresses.

[etotheipi]

If I understand correctly the new wallet format is primarily intended to support BIP 32, but will it also support non-deterministic or even "single-key" wallets?

The reason I ask is because I have imported my blockchain.info private key into an Armory wallet so that my ability to spend those funds is not limited to blockchain.info's uptime. In order to do this I had to make a regular deterministic wallet and manually add the key (which is fine), but I never had the option to dispense with the unneeded deterministic keys. It also means that any time I use Armory to initiate a transaction instead of the web client I must be careful to manually specify the change address to avoid sending it to the deterministic addresses.

Isn't this entirely resolved by the customizable change address option "Remember for future transactions"? (in expert usermode)

Let's say I was going to have wallets without any deterministic components, and without the ability to generate new addresses.  If you create such a wallet and import a key, and then you send a transaction... where is the change supposed to go?  How is Armory supposed to handle this?  The way I see it, there's only two real options: (1) send it back to one of the input addresses (first option), or let the user specify where to send it (second option).  Both options are available, and can be remembered between loads by checking the box.

The only gap I can think of is the case that the user wants to send change back to one of the input addresses, but not the first one.  Perhaps they want to see a list of input addresses used and want to pick one.  I can't see that being useful enough that it would be worth the implementation time.


Since this thread is titled "New Wallet Format", I will link to my other post where I mention a bunch of features the new wallet will have:

https://bitcointalk.org/index.php?topic=56424.msg1489639#msg1489639

That list may not be complete, but it should be enough to understand what I'm doing.  One thing I left out, is that it will have wallet-recovery challenges:  a user forgets their passphrase and wants help brute-forcing their wallet, but doesn't want to just post their entire wallet for everyone to see.  Armory will produce a nice block of text that they can post/email someone, which will fully describe a way to find the passphrase, but without giving the helper access to the wallet.  Furthermore, the person helping will be able to *prove* they found the passphrase, without actually giving it to the user.  Thus, they will be able to negotiate the terms of exchange.  I'd like to think it's not that useful, but I have had endless requests for help with this, and it's actually quite easy to implement ... so why not?

[justusranvier]

Isn't this entirely resolved by the customizable change address option "Remember for future transactions"? (in expert usermode)

Only if that option will remember different policies on a per-wallet basis. The way I manage my casual spending wallet is not the same as the way I manage my offline cold storage wallet.

Let's say I was going to have wallets without any deterministic components, and without the ability to generate new addresses.  If you create such a wallet and import a key, and then you send a transaction... where is the change supposed to go?  How is Armory supposed to handle this?  The way I see it, there's only two real options: (1) send it back to one of the input addresses (first option), or let the user specify where to send it (second option).  Both options are available, and can be remembered between loads by checking the box.

If the wallet only contains a single address then all change should go back to that address. That's how blockchain.info does it.

The only gap I can think of is the case that the user wants to send change back to one of the input addresses, but not the first one.  Perhaps they want to see a list of input addresses used and want to pick one.  I can't see that being useful enough that it would be worth the implementation time.

Does Armory support constructing a transaction where the inputs come from more than one wallet? That's the only possible case in which an ambiguity could arise in the use case I am talking about.

[etotheipi]

Isn't this entirely resolved by the customizable change address option "Remember for future transactions"? (in expert usermode)

Only if that option will remember different policies on a per-wallet basis. The way I manage my casual spending wallet is not the same as the way I manage my offline cold storage wallet.

Let's say I was going to have wallets without any deterministic components, and without the ability to generate new addresses.  If you create such a wallet and import a key, and then you send a transaction... where is the change supposed to go?  How is Armory supposed to handle this?  The way I see it, there's only two real options: (1) send it back to one of the input addresses (first option), or let the user specify where to send it (second option).  Both options are available, and can be remembered between loads by checking the box.

If the wallet only contains a single address then all change should go back to that address. That's how blockchain.info does it.

The only gap I can think of is the case that the user wants to send change back to one of the input addresses, but not the first one.  Perhaps they want to see a list of input addresses used and want to pick one.  I can't see that being useful enough that it would be worth the implementation time.

Does Armory support constructing a transaction where the inputs come from more than one wallet? That's the only possible case in which an ambiguity could arise in the use case I am talking about.

The "Remember for future transactions" does save the setting just for the wallet you're using.  I just verified that's how the code is written.  Let me know if you don't see it behave that way.

If the wallet has one address, then checking "send change to first input address" and "Remember" should forever keep the coins circulating through that single address.

Currently, Armory chokes when inputs come from multiple wallets.  At least it should -- I remember putting in error/warning messages about such transactions (at least for offline signing).  But I never tried it to see what would happen.

[justusranvier]

Here's the situation I'm running into:

In certain communities a lot of new people are getting involved with Bitcoin, and blockchain.info is their first wallet. Most of these people know nothing about the underlying technical details of how the protocol works.

I think blockchain.info is a perfectly fine wallet for new users to get started with because it's so easy to use, but I also think it's prudent for them to have their private key accessible in a standalone client. The wallet backup files blockchain.info generates helps non-technical users not at all if the site goes down so backups alone are not sufficient.

Normally that's what I recommend to people, but the issue of managing the change is a big barrier to their understanding. Most of these people don't know what coin control is, or how change addresses work, or even why change is generated in the first place.

That's why I was suggesting supporting the special case of a single-key wallet (possibly including the degenerate case of a single main key and one or more auxiliary receive-only keys). My main goal is to be able to point these novice users in the right direction towards a solution that ensures they never lose access to their bitcoins in the event of blockchain.info downtime, without overloading them with technical details they are not yet ready for.