Uncompressed private keys imported as segwit script types lead to unexpected addresses

[AbdussamadA]

This issue came up on IRC just now. Turns out armory uses p2sh segwit addresses but outputs uncompressed private keys beginning with 5. When you attempt to import/sweep them into electrum (even after appending p2wpkh-p2sh:) you get the wrong address because electrum assumes an uncompressed public key is at play here. Example:

p2wpkh-p2sh:5JKXxT3wAZHcybJ9YNkuHur9vou6uuAnorBV9A8vVxGNFH5wvTW

leads to: 3CLahY2835w9oRsAn49YreDYNTUeNE4pUm
expected: 33a94TSS1NLFzFiVhf4PQgvg9zsgMmz5tq

importing p2wpkh-p2sh:KySodjyx5BWMnnNghV2moeFxQVzy6VGDBn5HD1Ky8nvpmj4FoHzJ, which is the compressed version of the above priv key, leads to the expected address.

This affects uncompressed private keys imported or swept as p2wpkh as well.

Note that p2wpkh-p2sh and p2wpkh addresses must always use compressed public keys: https://bitcoincore.org/en/segwit_wallet_dev/ and https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type.

[SomberNight]

Is the requirement for compressed keys enforced on the consensus level, or is it policy?

When the user imports/sweeps/(etc??) an uncompressed segwit key, I guess we could either,

• display an error, or
• silently convert to a compressed key

Option2 sounds better to me.

[AbdussamadA]

Policy according to the bip: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type

Option 2 sounds good.

[AbdussamadA]

This affects uncompressed private keys that are imported/swept as p2wpkh too so I'm editing the OP to reflect that.

[neocogent]

This post on reddit mentions a user almost losing funds due to this.

https://www.reddit.com/r/Electrum/comments/bec22p/potential_loss_of_funds_if_import_uncompressed/

[rainysam]

I believe that I narrowly averted sending some BTC into a black hole by importing the wrong format of private key into Electrum recently.

When importing private keys into the current version of Electrum, the three script types available are p2pkh, p2wpkh-p2sh, and p2wpkh (aka legacy, p2sh-wrapped segwit, and native segwit, respectively). I imported a private key starting with a 5 from a paper wallet as p2wpkh-p2sh, and it generated an address for me, to which I then sent some BTC. It was a valid address starting with a 3 (in terms of the safety checksum) No error messages popped up indicating that it was an invalid address. I then tried to use that utxo in another transaction, before it confirmed. When I went to sign the txn, a message popped up saying something to the effect of "can't use uncompressed private keys in segwit addresses." Luckily, I learned this before the transaction confirmed, and I was the sender of the funding txn, so I was able to double-spend it to a different (legitimate) address.

The better time to have learned about this error would've been at the time of privkey import. When importing private keys as P2WPKH or P2WPKH-P2SH, and the privkey starts with a 5, a message should pop up explaining the issue. I'm unsure if there is a technical reason that would prevents this, though it seems straight forward.

Thought I'd share my experience in the hopes that it might save someone from making the same mistake. Most bitcoiners probably have no business fooling around with individual private keys anyway...current HD wallet technology makes the whole process much easier, and prevents making potentially costly mistakes.

Cheers.