I tried your wallet and got one address only, native segwit by default, to change into nested we should go to
settings,
Is moneypot using BIP39 mnemonic seed? because I don't see my address when putting it in the bip39 tool, If using BIP39 seed what derivation path of address?
thanks for your question, because this allows us to point out some of the beauty of moneypot.
So, with a regular wallet that uses BIP39, you take your mnemonic, convert it into a seed using PBKDF2, so far so good, this is what moneypot does client-side as well.
Now, moneypot does something similar to BIP32, but not exactly.
Most wallets using BIP32 would derive a master key from the seed using PBKDF2 and a salt. Then, from that master private key, they generate (mostly?!) hardened private keys while using a path like m/0/0'..
Now, what moneypot does, is that it takes your seed, and generates a private key out of it through a hash function, I assume it's mostly kind of similar to a standard BIP32 wallet up to this point. Derive the resulting public key, and you have your "xpub", or
claimantGenerator.
Because moneypot is a custodial wallet, the client can't just tweak the private key by an index to then derive the adress.
What we actually do is the following (although the next step is not really related to it being a custodial wallet) : We take the private key derived from the seed, and add another private key to it. The final result serves as our "child key". The added private key is the hash of an index parameter + the previously derived private key from our seed (see above), converted to a public key. I assume this is pretty standard too for most wallets.
This function is described
here.
This derivation function is equivalent to
claimantGenerator + hash(conc*t(index parameter, claimantGenerator))*G
as can be seen
here.
Deriving by the claimantGenerator allows you to generate addresses without access to the seed/private key, which could be useful in certain situations!
Note: This does mean that if one of your child keys + your xpub leak out, an attacker could probably access *what would be equivalent to* your "xpriv", just like all unhardened keys. However, this would only be a problem for new hookins which are accepted but not yet claimed, as the coins resulting from claims from hookins are not derived from the same private key, but rather from the wallet seed.
How do we actually do this? In the case of a public key for a deposit address, we take the private key from the seed, and we first derive it by it's purpose. In this case, it's a deposit address, so "bitcoinAddress".
After that, we take the resulting private key, and derive it again. This time we derive by the index. Let's say it's our first key, so we derive by 0.
And you get
k(index, purpose) = k"Master" + h(xpub + purpose) + h(xpub, index) % n
You can check it out here We end up with a private key that's actually a key for a yet to exist "bitcoinAddress 0". Let's call the public key resulting from this private key "
claimant bitcoinAddress 0"
However, we do not want to derive an address from this key and subsequently send this key to the custodian, because then we would not be able to prove that we initiated or signed certain actions pertaining to this address. Such as claiming coins!
So what do we do? We hash the resulting public key again, and convert the hash into a private key. From that private key, we derive the public key, and then add the public key to the custodian's fundingKey.
From the resulting public key, we derive either a nested segwit address, or native.
The database function is described
here and the function to add the public keys together is described
here. Although, they're not really that interesting because it still hides the abstracts away.
Now, whenever we deposit funds on bitcoinAddress 0, we send a hookin to the custodian using "
claimant bitcoinAddress 0". The custodian derives the private key from "
claimant bitcoinAddress 0" and can subsequently claim the bitcoins deposited on the address. Now, because the custodian does not know the private key
to the
claimant, only you, the client, can initiate a claim! thus making it provably-fair, as the custodian will be unable to provide a valid signature for the
claimant, and thus cannot falsely claim that your coins have already been claimed.
Of course, you could also send us your
claimant and ask us for a deposit address, but that solution would not be as elegant, would it? (This is exactly what we do for lightning invoices though!)
So, no. You cannot use any standardized third-party tool to derive your deposit addresses, for moneypot is far too "un-standard". However, it wouldn't be too hard to come up with an api to generate keys following the same derivation as the wallet does.
Let us know if anything was vague, or if it was too technical.
OK, I'm obviously missing something here.
Custodial wallet with full access to user funds
A domain with a dubious past
Newbie account on the forum
What could possibly go wrong?
No, you're not missing much. I'd say that that is about right. Sure, there are a lot of things that
can go wrong, but we believe that this could also blossom into something cool, otherwise we wouldn't have started it.
I'm not dismissing your concerns, I think they are understandable, obviously we do hope you change your mind sooner or later.