You might want to take a look at this: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
Though I'd proceed with caution, as you are designing a wallet holding other peoples money.
Topic: Combining addresses for space conservation on Mobile Phones (Read 1337 times)
That does sound like a better way to go... It's kind of interesting how many addresses you can get out of a few priv/pub key pairs, though.
Why not just store an HD seed (or Master Public Key if you don't want to store private keys on your table) and just store indexes instead of addresses?
Then when you actually need the address, the local client just calculates the seed/MPK with the CKD function to the index you need.
Then when you actually need the address, the local client just calculates the seed/MPK with the CKD function to the index you need.
I know P2SH != m-of-n multisig, P2SH is much more general. But it can be used for m-of-n multisig, and that is what I was referring to here.
P2SH != m-of-n multisig
I'm part of a team making a mobile wallet for cryptocurrency. We have a database of addresses, and I was thinking about ways that we might be able to conserve space in this table.
So suppose the user has 5 priv/pub key pairs. Then I think we can actually get
Unique addresses from these 5 key pairs. We can do this because we can use different addresses in the redeemScript and we can rearrange the order of those addresses.
Is this a viable system? Is there some reason why it would not be a good idea to do this?
It probably wouldn't produce the greatest anonymity. And another problem is that using all these addresses might cause a bit of blockchain bloat, and it would make the transactions bigger and cause the user to need to pay larger fees. So while this is an interesting idea, I don't see us actually using this method in our wallet.
So suppose the user has 5 priv/pub key pairs. Then I think we can actually get
(P2PKH):
5 +
(P2SH):
5 (1 of 1) + 20 (1 of 2) + 60 (1 of 3) + 120 (1 of 4) + 120 (1 of 5) +
20 (2 of 2) + 60 (2 of 3) + 120 (2 of 4) + 120 (2 of 5) +
60 (3 of 3) + 120 (3 of 4) + 120 (3 of 5) +
120 (4 of 4) + 120 (4 of 5) +
120 (5 of 5)
= 1310
Unique addresses from these 5 key pairs. We can do this because we can use different addresses in the redeemScript and we can rearrange the order of those addresses.
Is this a viable system? Is there some reason why it would not be a good idea to do this?
It probably wouldn't produce the greatest anonymity. And another problem is that using all these addresses might cause a bit of blockchain bloat, and it would make the transactions bigger and cause the user to need to pay larger fees. So while this is an interesting idea, I don't see us actually using this method in our wallet.
Jump to: