Topic: Seeds segwit to standard? (Read 322 times)

I was testing something on android electrum, put in my public key (scanned as a qr coee) and it looked as if it was copied correctly but the box was greyed out...

I'm trying to do some sort of multisig but it's probably not worth the hassle and I might just go to what I was saying in the previous post and just keep a key in my head... Android electrum doesn't seem to like signing from cold storage either.

Yeah... that was kinda my point.

Unless you have the actual seed mnemonic (or the seed generated from that mnemonic)... you cannot simply convert an xpub to a ypub (or zpub) and start generating the same P2SH-P2WPKH (or bech32) addresses that you would get if you started from the seed in the first place.

the xpub will be generating keys on the m/44'/0'/0' path... so an xpub-to-ypub conversion will also start generating keys/addresses from that same path... whereas, the "real" ypub that you would normally generate from the same seed would (should?) have started generating address from the m/49'/0'/0' (and a zpub from m/84'/0'/0')


In short, you can't convert "properly" without the original seed (or seed mnemonic)


Most wallet apps that I know of only allow a single xpub per wallet. ie. You can't open a wallet file and import multiple xpubs... However, Mycelium allows you to import multiple xpubs(/ypubs/zpubs)... it's a bit "hidden", but it works... You need to copy/paste the xpub/ypub/zpub... and then within Mycelium use: "Add Account -> Advanced -> Clipboard".

I've just created a new wallet in Mycelium that has the main "HD-Account" from a normal seed mnemonic... and 3 "imported" watching-only accounts using the xpub, ypub and zpub that I posted above.

However, I'm not sure if this will be of any use to you in the long run if you're attempting to setup some sort of airgapped system, as you can't generate an unsigned transaction from Mycelium and then transfer to another device to sign etc.

I don't think that you're saying is possible.

You can't convert derivation paths unless you have multiple public keys and even then it might not be possible.

I have since given up on this idea as my wallets won't accept xpubs anymore On Android for some unknown reason... I've to thought of moving to a new idea where I have a public key on my computer and the seed in a tight cold storage in my head.

To be honest... I don't think that converter is doing what I thought it might be... on delving into the code... all it does is strip the 4 version bytes and replace them with new version bytes. So, while it is converting an Xpub to a Ypub for instance, it isn't the "matching" ypub...

From the SLIP-0132 Test Vectors:

However, that converter converts:
xpub6BosfCnifzxcFwrSzQiqu2DBVTshkCXacvNsWGYJVVhhawA7d4R5WSWGFNbi8Aw6ZRc1brxMyWM zG3DSSSSoekkudhUd9yLb6qx39T9nMdj
to
ypub6We8xsTdpgW67F3ZpmWU77JgfS29gpX5Y2u6HfSBsW5ae2yLsiae8WAQGaZJ85b1y4ipMLYvSAi Y9Kq1A8rpSzSWW3B3jtA5Na1gXzZ8iqF

instead of:
ypub6Ww3ibxVfGzLrAH1PNcjyAWenMTbbAosGNB6VvmSEgytSER9azLDWCxoJwW7Ke7icmizBMXrzBx 9979FfaHxHcrArf3zbeJJJUZPf663zsP


I believe what it is doing, is converting the m/44'/0'/0' derivation path xpub to a m/44'/0'/0' derivation path ypub... in other words, it'll be deriving P2SH-P2WPKH addresses using a derivation path of m/44'/0'/0' instead of the "correct" derivation path of m/49'/0'/0'... I'm not sure if this is the behaviour you were actually wanting, or if you want to be able to convert a m/44'/0'/0' xpub to a m/49'/0'/0' ypub (or m/84'/0'/0' zpub)...

I need to do the same thing with the xprv though at some point.

My issue with that is that it'll work if it's very accurate and I am then it'll work fine... Until I need to spend the coins of course. But thanks that might be more secure...

Just to go back to your original query... I stumbled across this today and thought of this thread: https://jlopp.github.io/xpub-converter/

I have to say I don't like the idea of 2fa much myself but I guess that's true. I was experimenting with cold storage with an offline fphone but Android doesn't seem to be supportive of it (I'm guessing it's one of the things they had to cut although I was using different versions of electrum - but they both knew what segwit was and I was sending legacy to legacy).

Well if you know what you are doing you don't need to use the electrum 2fa wallets. You can create your own multisig 2fa setup using 2 devices like a pc and a phone and save fees that would otherwise go to trusted coin and the electrum developers. So the people using 2fa are relative noobs and it is important that restoration from seed be relatively painless for these guys. When you restore from seed electrum can automatically detect that it's a 2fa wallet.  So that's why there's a 2fa version.

It seems weird the 2fa ones aren't although the 2fa probably cane in long after the multisig was added so maybe it makes sense...

(I don't actually have a computer at the moment - at least not near me other than my phones - I'll have to run that script next week) .

You're right about this. non-2fa multisig wallets don't have a separate version encoded in the seed mnemonic:

https://github.com/spesmilo/electrum/blob/3.3.2/electrum/version.py

@jackg I updated that script to work with electrum 3.3.2 just now. If it's not working for you try the newest version.

Abdumassad is kind of right. .
However, p2pkh multisig is the same address and extended public key so it's the same derivation path. I'm not sure if that's what you meant with the list?I'll check out that tool anyways.

At this rate its probably best to either use another seed or start using a load of paper to generate the private key and then convert it to an address...

---

Electrum uses odd bip32 derivation paths also I think so this might get even more confusing...

This is not true in the case of electrum. It encodes the script type in the seed mnemonic and that's how it knows whether to generate p2pkh, p2sh multisig, p2wpkh or p2wsh multisig addresses. It doesn't let you mix the various types in the same deterministic wallet.

jackg see the last sentence that I wrote  above ^

Regarding xpub to zpub you will have to convert the key using software because there is a checksum and it won't validate if you simply change a letter. Here's a script that can do it for you.

(Edit: I was thinking in terms of BIP39 only, Electrum does it differently, read comment below)
Your seed words are the human readable representation of the entropy that you use to generate your keys. There is no difference* between a SegWit seed and a regular seed, in the end you are generating "private keys" and in bitcoin we only have one type of private key!
The final step is when you can decide to encode the corresponding public key to be a P2PKH output (base58 address) or a P2WPKH (bech32) or a P2WSH (base58 but starting with 3).

What the first couple of letters (xprv, yprv, tprv,...) are telling your code behind is exactly the last step otherwise everything else is the same. And those letters are representing 4 bytes which can not be changed otherwise the  checksum (the last 4 bytes) would become wrong.

* There is an additional tiny difference and that is the derivation path which uses m/84'/../../.. so technically if you change your xprv to a zprv you won't get the same private keys unless you override this path difference but the "roots" are exactly the same.

Is there a way to convert a standard seed into a segwit one? I also want to know if I change the first letter on an xpub to z is it then a zpub or is it completely different checksum wise?