bip39
bip39 copied to clipboard
Please Help me!
I created a wallet for XRP using this tool, I clicked the option to "encrypt private keys using BIP39 and this password" I entered a password. I used the generated address and like a dumbass did not test the account after transfering. Now I have an account I cant seem to acess because the "private" key does not allow me acess to the R address. Does this mean my money is doomed to a black whole account? or is there a way that I can somehow salvage this? how does the encryption option change from the memonic seed? how can I gain control of this account to transfer it into a normal wallet? I really need help with this please.
Langley, [email protected]
@iancoleman I have never used the BIP38 encoding in this app, but also got confused trying to see what Langley ran into. See first if this is true:
Setup
- Enter
abandon abandon ability
into "BIP39 Mnemonic field". - Make sure
BTC
(default) is selected as a coin. - Go to the bottom of the Derived Addresses section and just above the More info header, set the number of generated addresses to 1 to save yourself some time.
- Enter
password123
into the "Encrypt private keys using BIP38 and this password" field, but do not tick the checkbox yet. The private key field form/44'/0'/0'/0/0
shows the WIFL26cVSpWFkJ6aQkPkKmTzLqTdLJ923e6CzrVh9cmx21QHsoUmrEE
and the p2pkh address is1Di3Vp7tBWtyQaDABLAjfWtF6V7hYKJtug
. - Now tick the BIP38 checkbox and wait for the calculation to happen.
Observation
- The private key field for
m/44'/0'/0'/0/0
properly shows6PRNRiFni4KN2cVshC2jks8W4zvHnfV3SYx4mP9FbePVCirzUm7GQywypp
. - The address and public key fields change on that row, suggesting they were calculated from the encrypted WIF.
Expectation
- Since BIP38 is just an alternative storage format for private keys, the public key and therefore the p2pkh address should still be calculated from the decrypted/original private key.
Will this work for XRP when it’s set to bitcoin? I find it hard to understand the process but I will sit down and dedicate my next day off to try and follow this guide. Thank you for your help
Sent from my iPhone
On Jan 24, 2022, at 03:08, wigy @.***> wrote:
@iancoleman I have never used the BIP38 encoding in this app, but also got confused trying to see what Langley ran into. See first if this is true:
Setup
Enter abandon abandon ability into "BIP39 Mnemonic field". Make sure BTC (default) is selected as a coin. Go to the bottom of the Derived Addresses section and just above the More info header, set the number of generated addresses to 1 to save yourself some time. Enter password123 into the "Encrypt private keys using BIP38 and this password" field, but do not tick the checkbox yet. The private key field for m/44'/0'/0'/0/0 shows the WIF L26cVSpWFkJ6aQkPkKmTzLqTdLJ923e6CzrVh9cmx21QHsoUmrEE and the p2pkh address is 1Di3Vp7tBWtyQaDABLAjfWtF6V7hYKJtug. Now tick the BIP38 checkbox and wait for the calculation to happen. Observation
The private key field for m/44'/0'/0'/0/0 properly shows 6PRNRiFni4KN2cVshC2jks8W4zvHnfV3SYx4mP9FbePVCirzUm7GQywypp. The address and public key fields change on that row, suggesting they were calculated from the encrypted WIF. Expectation
Since BIP38 is just an alternative storage format for private keys, the public key and therefore the p2pkh address should still be calculated from the decrypted/original private key. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.
Yeah, sorry, @DEVINEUS, I just tried to ask the big guys this question before I could try to help you. If you are able to import your encrypted secret key into a Ripple wallet without telling it that it is actually encrypted, and it shows you the same address that this tool showed you, then you will probably be able to transfer it to another address. If not, that still does not mean you are screwed, but you will need to find a wallet that calculates the same address where you have your balance.
This tool uses compressed public keys, but when bip38 is enabled it uses uncompressed keys, which is why the address is different.
The relevant code and comments are here: https://github.com/iancoleman/bip39/blob/e2fdc5b9420fe45a255776f0caa6df8b0baf4a2c/src/js/index.js#L1238-L1247
The reason bip38 uses uncompressed keys is detailed here: https://github.com/iancoleman/bip39/issues/140#issuecomment-352164035
Using the example steps from @wigy-opensource-developer with the bitcoin key compression tool at https://iancoleman.io/bitcoin-key-compression/ gives consistent results with this tool.
The input public key is
033f5aed5f6cfbafaf223188095b5980814897295f723815fea5d3f4b648d0d0b3
The compressed address matches what is shown without bip38 enabled
1Di3Vp7tBWtyQaDABLAjfWtF6V7hYKJtug
The uncompressed address matches what is shown with bip39 enabled
1NCvSdumA3ngMM9c4aqU56AM6rqXddfuXB
But it might be worth adding an explicit option for compressed / uncompressed keys to this tool.
Wow. I am ashamed I have not noticed the longer public key. So basically if @DEVINEUS finds a Ripple wallet that supports P2PKH addresses based on uncompressed public keys, he is fine? Most BTC wallets dropped support for uncompressed keys because of the bigger transaction sizes. Maybe someone knows a Ripple one that still supports them?
I do not want to worry Langley too much, but the official Ripple documentation only talks about 33 byte public keys (compressed): https://xrpl.org/cryptographic-keys.html#key-components