Topic: bip32 wallet structure for electrum (Read 4114 times)

Regarding #2 the ascii names... that's better suited to an external mechanism (ex: take the public key, derive some unique value, and use the Label sync service out there).

If integers were not used, then BIP32 fails since it relies on this fact for calculations.


#3 not sure, but that is a feature on my down-the-road task for my Java library + Android app... months due to time constraints and getting the initial release out

#4 - I'll have a Java library capable of mucking around with BIP32 values, so... writing up an additional tool would not be difficult at all (though I bet a python tool would be quicker at the moment)

#5 - if you were somehow able to buy time itself, I could do it ... however... extending the hours in a day in such a way that sanity is maintained - well... that's more like the work for a Time Lord...

And for completeness, for #1... I'm not sure how that's supposed to work out at all. Perhaps multisig addresses are addresses that would be associated with multisig - that way they would be separated from normal transactions - that way you could simplify user interface...

Anyone with any comment?

I am very interested in Hierarchical Deterministic wallets.

I have a few questions, please forgive me if I am misunderstanding something here.

1) In adding what is essentially a type layer of multisig type, isn't that adding a hierarchical layer that isn't in the BIP?  I understand how the math makes that possible I'm just concerned about interoperability with other solutions.

2) Is there any reason that n has to be an integer?  For example, I was thinking it would be cool to be able to create accounts with ascii names.  Of course for recovery the user would have to know their seed and the names of their accounts in order to rediscover the tree.  Actually, this sounds like a really bad idea.  I think the coolest, most important feature of Electrum is the ability to recover from one human readable string.

3) Will someone be able to create an account, lets says m/0'/7' and then load up an electrum client with just that, without any visibility or awareness of the other chains in the tree?

4) Will the equivalent of the master public key for such an account work with existing electrum address generators like (https://github.com/prusnak/addrgen)?

5) Who can I bribe/bounty/pay for this work to be done?  I would try to help but python is certainly not my strong suit and my EC knowledge is very low.  I'd be willing to pony up 25 BTC if it would help.

That would mean all private keys for 2of2 and 2of3 accounts are derived from a single master key and therefore two co-operating persons cannot each generate a private (sub-)master key themselves and share the public part.

are you panning to have a lookahead limit that electrum tries to enforce, in order to make recovery easy?

hum, I realize now that a /private/private derivation for normal accounts will prevent wallet synchronization accross machines.

To fix that, it should probably be /private/public, that is, m/0'/n/ 
The type 2 derivation will allow electrum to discover newly created accounts over different machines, like it currently does for addresses within its main account.

Therefore, both normal and multisig accounts should use a /private/public derivation.

Looks good to me.

Electrum is going to use Hierarchical Deterministic wallet (bip32)

In order to preserve the capability to restore a wallet from its seed, it is now necessary to adopt a convention concerning address allocation.

For the moment I think it would be a bit overkill to restore an entire tree using a tree exploration algorithm, although this might be the case in the future.
I just want to use a simple convention for enumerating accounts derived from a seed.

Here is how I plan to do it:

m/0'/n'/   :   normal accounts, where n is an integer.
m/1'/n/ & m/2'/n/  : "multisig 2of2" accounts.
m/3'/n/ & m/4'/n/ & m/5'/n/ : "multisig 2of3" accounts

In this scheme, each account has a sequence of receiving and change addresses.
example:
m/0'/n'/0/k -> receive addresses
m/0'/n'/1/k -> change addresses

As per bip32 conventions, the prime symbole (') refers to private (type1) derivation, while "no prime" means public (type2) derivation.

Note that normal account creations use private derivation, so the user will need to enter their password in order to generate a new account.
m/0'/ is sufficient to generate normal accounts, so that "m/" (the master key) can be thrown away.

Multisig accounts may be only partially seeded. (for example, we keep m/1'/ and throw away m/ and m/2'/)
Multisig accounts use a private derivation at level 1, and a public derivation at level 2; this is to avoid having to receive master public keys from an external wallet or service when an account is created.

Let me know if you think I missed something.