Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Please Help me! #569

Open
DEVINEUS opened this issue Jan 22, 2022 · 5 comments
Open

Please Help me! #569

DEVINEUS opened this issue Jan 22, 2022 · 5 comments

Comments

@DEVINEUS
Copy link

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,
Robitaille.langley@gmail.com
@wigy-opensource-developer
Copy link

@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.

@DEVINEUS
Copy link
Author

DEVINEUS commented Jan 25, 2022 via email

@wigy-opensource-developer
Copy link

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.

@iancoleman
Copy link
Owner

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:

bip39/src/js/index.js

Lines 1238 to 1247 in e2fdc5b

// bip38 requires uncompressed keys
// see https://github.com/iancoleman/bip39/issues/140#issuecomment-352164035
var keyPair = key.keyPair;
var useUncompressed = useBip38;
if (useUncompressed) {
keyPair = new libs.bitcoin.ECPair(keyPair.d, null, { network: network, compressed: false });
if(isGRS())
keyPair = new libs.groestlcoinjs.ECPair(keyPair.d, null, { network: network, compressed: false });
}

The reason bip38 uses uncompressed keys is detailed here: #140 (comment)

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.

@wigy-opensource-developer
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@iancoleman @wigy-opensource-developer @DEVINEUS