Zpub safety

[gunrs17]

For multisig you have to have all Zpubs in order to spend.  What are the risk associated with savings your list of Zpubs on google drive or the likes so that you can access them from anywhere.

[1714079496]

1714079496

[1714079496]

1714079496

[1714079496]

1714079496

[DaCryptoRaccoon]

Probably not the best idea even if your need more than one of them to spend.

If your going to the trouble of using Multi-Sig then why keep the keys online?

Seems pretty stupid.

[ranochigo]

Unhardened keys will let an adversary be able to obtain your master private key with your master public key and any individual public private key from that keypair. This shouldn't be a problem because you are not supposed to expose any of your addresses anyways.

The far greater concern is with the privacy. Any attacker with all of the master public keys, will know all of the possible addresses generated that can be generated with your multisig, provided that they also know your derivation path. The latter should be a given, any complex and non-standard derivation path could result in the user lose all their funds if they don't save it properly.

[BitMaxz]

It's a master public key if someone has access to this then they can only see all of your addresses on that zpub but they can't make any transaction.

If it was from multisig wallet then even you have them you won't be able to make transactions because it is just a master public key.
You can make an unsigned transaction from zpub but you won't be able to broadcast them so if you want it to become valid you will need to sign them.

What exactly do you want to achieve here?

[gunrs17]

Probably not the best idea even if your need more than one of them to spend.

If your going to the trouble of using Multi-Sig then why keep the keys online?

Seems pretty stupid.

Im only talking about keeping the Zpubs online, you can't spend with just Zpubs.  you also need the private keys which of course would not be stored online.  Im curious if there are risk involved with storing public keys(Zpubs in this example) online.

[n0nce]

Probably not the best idea even if your need more than one of them to spend.

If your going to the trouble of using Multi-Sig then why keep the keys online?

Seems pretty stupid.

Im only talking about keeping the Zpubs online, you can't spend with just Zpubs.  you also need the private keys which of course would not be stored online.  Im curious if there are risk involved with storing public keys(Zpubs in this example) online.

You already got the correct answer from BitMaxz: zpub is a public key; people that have it can see your addresses, but can't spend your funds.

It's a master public key if someone has access to this then they can only see all of your addresses on that zpub but they can't make any transaction.

The one risk you are running here, is your privacy. By knowing your public keys, it can be traced who you pay (e.g. if you send funds to coinbase or gambling sites etc).

[NotATether]

You already got the correct answer from BitMaxz: zpub is a public key; people that have it can see your addresses, but can't spend your funds.

It's a master public key if someone has access to this then they can only see all of your addresses on that zpub but they can't make any transaction.

This is not entirely correct - See ranochigo's reply above and also this thread.

Publishing (or leaking) a derived address/privkey pair allows anybody to use the master-zpubs to generate the master-zprivs and with that, any private key that can be derived by the master private keys.

[n0nce]

You already got the correct answer from BitMaxz: zpub is a public key; people that have it can see your addresses, but can't spend your funds.

It's a master public key if someone has access to this then they can only see all of your addresses on that zpub but they can't make any transaction.

This is not entirely correct - See ranochigo's reply above and also this thread.

Publishing (or leaking) a derived address/privkey pair allows anybody to use the master-zpubs to generate the master-zprivs and with that, any private key that can be derived by the master private keys.

Oh well I was under the assumption that nothing except that master public key was leaked. I know about that unfortunate bug; anyone should sweep their whole wallet if they know a single private key got leaked (though I don't see how leaking a private key should happen if you have your opsec in check).

[o_e_l_e_o]

Publishing (or leaking) a derived address/privkey pair allows anybody to use the master-zpubs to generate the master-zprivs and with that, any private key that can be derived by the master private keys.

Leaking a single private key would only allow an attacker to use that private key and the corresponding master public key to derive a single master private key. In the case of a multi-sig wallet, funds would still be safe since the attacker would only have one master private key, and not the threshold number of master private keys. For the coins to be at risk, OP would have to leak multiple private keys derived from different master private keys, which is very unlikely if his multi-sig wallets are all stored separately (as they should be) and he takes reasonable security precautions.


Throughout this thread, people are using Zpub and zpub interchangeably. They are not the same thing. zpubs are for P2WPKH addresses, Zpubs are for P2WSH addresses. See here for more info: https://github.com/satoshilabs/slips/blob/master/slip-0132.md

[gunrs17]

Publishing (or leaking) a derived address/privkey pair allows anybody to use the master-zpubs to generate the master-zprivs and with that, any private key that can be derived by the master private keys.

Leaking a single private key would only allow an attacker to use that private key and the corresponding master public key to derive a single master private key. In the case of a multi-sig wallet, funds would still be safe since the attacker would only have one master private key, and not the threshold number of master private keys. For the coins to be at risk, OP would have to leak multiple private keys derived from different master private keys, which is very unlikely if his multi-sig wallets are all stored separately (as they should be) and he takes reasonable security precautions.


Throughout this thread, people are using Zpub and zpub interchangeably. They are not the same thing. zpubs are for P2WPKH addresses, Zpubs are for P2WSH addresses. See here for more info: https://github.com/satoshilabs/slips/blob/master/slip-0132.md

I'm only talking about Zpubs. I'm a little confused about how we have gotten to the leaking of a private key?  It 100% impossible to obtain A private key from a Zpub(or any derivation of a master public key).  And to my original question...In the case of a multisig wallet if someone stores all of their Zpubs in an unsecure place, the only risk is privacy, correct?  You are just giving someone the ability to create a watching-only wallet, correct?

[o_e_l_e_o]

I'm a little confused about how we have gotten to the leaking of a private key?

Because the combination of a Zpub plus any one individual private key is enough to derive the Zprv and all the associated individual private keys.

It 100% impossible to obtain A private key from a Zpub(or any derivation of a master public key).

Correct.

And to my original question...In the case of a multisig wallet if someone stores all of their Zpubs in an unsecure place, the only risk is privacy, correct?  You are just giving someone the ability to create a watching-only wallet, correct?

Mostly correct. There is a hypothetical security risk in the scenario described above where you have accidentally leaked a private key, and there is the also the concern that if someone can recreate your watch only wallet and see how much bitcoin you own, that they may target you specifically for further attacks.

[gunrs17]

I'm a little confused about how we have gotten to the leaking of a private key?

Because the combination of a Zpub plus any one individual private key is enough to derive the Zprv and all the associated individual private keys.

I'd like to understand this completely in reference to a multisig setup.  Let's use a 2 of 3 multisig as an example.  If someone were to have all 3 of the Zpubs and then you accidentally leaked one of your private keys.  Is it possible to derive the 2nd private key?  And if so then the attacker can sign a transaction from this wallet.

[ranochigo]

I'd like to understand this completely in reference to a multisig setup.  Let's use a 2 of 3 multisig as an example.  If someone were to have all 3 of the Zpubs and then you accidentally leaked one of your private keys.  Is it possible to derive the 2nd private key?  And if so then the attacker can sign a transaction from this wallet.

No. The private key only allows you to derive the master private key for that specific Zpub in question, it does not compromise the other Zpubs. However, since the attacker has one of your Zpriv (master private key), the attacker can use that master private key to sign for transactions, assuming another person is willing to sign it too. A single compromised Zpub and private key doesn't affect the other signers.

[gunrs17]

I'd like to understand this completely in reference to a multisig setup.  Let's use a 2 of 3 multisig as an example.  If someone were to have all 3 of the Zpubs and then you accidentally leaked one of your private keys.  Is it possible to derive the 2nd private key?  And if so then the attacker can sign a transaction from this wallet.

No. The private key only allows you to derive the master private key for that specific Zpub in question, it does not compromise the other Zpubs. However, since the attacker has one of your Zpriv (master private key), the attacker can use that master private key to sign for transactions, assuming another person is willing to sign it too. A single compromised Zpub and private key doesn't affect the other signers.

Ok yes that was always my understanding.  I just misunderstood The previous commenter's point.  Thanks!

[Jason Brendon]

Throughout this thread, people are using Zpub and zpub interchangeably. They are not the same thing. zpubs are for P2WPKH addresses, Zpubs are for P2WSH addresses. See here for more info: https://github.com/satoshilabs/slips/blob/master/slip-0132.md

zpubs or Zpubs are bad ideas. They should not have been created. And there are plenty of misunderstandings out there.
Since zpubs or Zpubs are already for P2WPKH or P2WSH, then what's the alphabets for taproot?
People should always use xpub and descriptor.

[NotATether]

Throughout this thread, people are using Zpub and zpub interchangeably. They are not the same thing. zpubs are for P2WPKH addresses, Zpubs are for P2WSH addresses. See here for more info: https://github.com/satoshilabs/slips/blob/master/slip-0132.md

zpubs or Zpubs are bad ideas. They should not have been created. And there are plenty of misunderstandings out there.
Since zpubs or Zpubs are already for P2WPKH or P2WSH, then what's the alphabets for taproot?
People should always use xpub and descriptor.

xpub is for generating the legacy 1 addresses and various altcoin addresses like doge, dash that didn't implement Segwit.

Taproot doesn't have its own extended version bytes because Taproot UTXOs also are P2WPKH just like native segwit, so they use the same "zpub"/"zprv".

On the other hand, if you are using Taproot leaf spending feature, that's also an extension of P2WSH bc1q script addresses and so you should also be using "Zpub"/"Zprv" extended version bytes.

[o_e_l_e_o]

zpubs or Zpubs are bad ideas. They should not have been created. And there are plenty of misunderstandings out there.
Since zpubs or Zpubs are already for P2WPKH or P2WSH, then what's the alphabets for taproot?
People should always use xpub and descriptor.

I do agree it would have been easier to just stick to xprvs/xpubs and then specify derivation path/script type/etc. separately in order to generate the correct type of addresses, which is exactly what Core is doing with descriptors. It would avoid scenarios like this one where you have to convert Zprvs from Electrum to xprvs in order to import them in to Core.

As specified in BIP86, Taproot should use xprvs/xpubs, but there is nothing stopping software using zprvs/zpubs for Taproot. Although given that Taproot addresses can be key path or script path, then the whole Z/z separation for script hash/pubkey hash falls apart.


Would you mind editing your post to fix your misquote?

xpub is for generating the legacy 1 addresses

This is a common misconception. xprvs/xpubs are defined in BIP32, which says nothing about what type of addresses they should be used to generate. They are simply extended keys, and can be used for any address type, which is exactly what Bitcoin Core does. You are obviously right in saying that a lot of software treats xprvs/xpubs as meaning legacy addresses, but this is not strictly correct.

As I've linked to above, BIP86 uses xprvs/xpubs for Taproot, not zprvs/zpubs as you suggest.

[NotATether]

As I've linked to above, BIP86 uses xprvs/xpubs for Taproot, not zprvs/zpubs as you suggest.

Got it. It's a bit annoying though that the bech32 addresses do not use consistent extended version bytes, as if the vast array of bytes is not inconsistent enough currently, and it makes for a kind of frustrating experience in coding wallet software.

[Jason Brendon]

zpubs or Zpubs are bad ideas. They should not have been created. And there are plenty of misunderstandings out there.
Since zpubs or Zpubs are already for P2WPKH or P2WSH, then what's the alphabets for taproot?
People should always use xpub and descriptor.

I do agree it would have been easier to just stick to xprvs/xpubs and then specify derivation path/script type/etc. separately in order to generate the correct type of addresses, which is exactly what Core is doing with descriptors. It would avoid scenarios like this one where you have to convert Zprvs from Electrum to xprvs in order to import them in to Core.

As specified in BIP86, Taproot should use xprvs/xpubs, but there is nothing stopping software using zprvs/zpubs for Taproot. Although given that Taproot addresses can be key path or script path, then the whole Z/z separation for script hash/pubkey hash falls apart.


Would you mind editing your post to fix your misquote?

xpub is for generating the legacy 1 addresses

This is a common misconception. xprvs/xpubs are defined in BIP32, which says nothing about what type of addresses they should be used to generate. They are simply extended keys, and can be used for any address type, which is exactly what Bitcoin Core does. You are obviously right in saying that a lot of software treats xprvs/xpubs as meaning legacy addresses, but this is not strictly correct.

As I've linked to above, BIP86 uses xprvs/xpubs for Taproot, not zprvs/zpubs as you suggest.

I just fixed my misquote, really suck on this thing.

xpub is xpub, it should stick to bip32 and that's it. The others? let descriptor to handle them.

I hate all the flying around ypub Ypub, zpub, Zpub, different wallets are doing things differently. This create huge problesm when one wants to move from one wallet to another.

Electrum also does that.. which is a bad move...

[NotATether]

I just fixed my misquote, really suck on this thing.

xpub is xpub, it should stick to bip32 and that's it. The others? let descriptor to handle them.

I hate all the flying around ypub Ypub, zpub, Zpub, different wallets are doing things differently. This create huge problesm when one wants to move from one wallet to another.

Electrum also does that.. which is a bad move...

I believe that if Electrum and other wallets have an option to select the extended version bytes manually in an advanced setting, then the problem will be alleviated. However, I'm not quite sure how the hex characters correspond to these base58 prefixes.