Can a watch-only wallet sign messages from its addresses?

[NotATether]

I'm about to create a watch-only wallet so I can copy my addresses more easily without having to worry about the safety of my private keys. Because private keys are not in the watch only wallet will I not be able to sign a message from it?

The master key can generate all the bitcoin addresses of the wallet, and I think also their public keys, as an address is just a portion of the public key. But a signed message needs both the address and private key to work, doesn't it?

[1714818306]

1714818306

[1714818306]

1714818306

[1714818306]

1714818306

[1714818306]

1714818306

[1714818306]

1714818306

[hosseinimr93]

No, you cannot sign message using a watch-only wallet.
For signing a message form an address, you need the private key of that address. Since the watch-only wallet doesn't include the private key, it's impossible to sign a message.

Also note that people usually sign message from an address to prove their ownership. If you don't have the private key of an address, it means that you aren't the owner of that address. So, it doesn't make sense to be able to sign message from an address without having its private key.

[Pmalek]

The master key can generate all the bitcoin addresses of the wallet, and I think also their public keys...

Your master public key will generate the same bitcoin addresses, correct. If somehow your master public key were to be leaked, all your public keys could be revealed as well. That wont be enough to steal your Bitcoin though. 

[o_e_l_e_o]

The master key can generate all the bitcoin addresses of the wallet, and I think also their public keys, as an address is just a portion of the public key.

Your main question has been answered above, but there are a few inaccuracies in the other things you wrote which it would be worth clearing up to avoid any confusion you may have in the future.

There is no such thing as a single "master key". There are "master private keys" and "master public keys". The master public key can generate all the individual public keys and all the individual addresses in your wallet. Going up a level, the master private key can generate all this as well as all the individual private keys in your wallet. The master private key is also used to generate the master public key. Further, it is not accurate to say that an address is a "portion" of the public key. An address is calculated from the public key using hash functions, specifically SHA256 followed by RIPEMD160.

In the case of a watch only wallet which is generated from a master public key, you will be unable to sign a message.
If you were to create a full wallet using your master private key, you then would be able to sign a message.

[Abdussamad]

I'm about to create a watch-only wallet so I can copy my addresses more easily without having to worry about the safety of my private keys. Because private keys are not in the watch only wallet will I not be able to sign a message from it?

no. also when we talk about spending bitcoin we say we sign transactions not messages. messages implies arbitrary content.

The master key can generate all the bitcoin addresses of the wallet, and I think also their public keys, as an address is just a portion of the public key. But a signed message needs both the address and private key to work, doesn't it?

the master public key (xpub or mpk) can generate all public keys. an address is the hash of the public key. it's not a portion of the public key. an xpub can also be used to generate addresses. it cannot be used to derive private keys.

to spend bitcoin you need the private keys. the address is not required because it can be derived from the public key which can be derived from the private key.

note there is also such a thing as a master private key which lets you derive all private and public  keys and corresponding addresses. it begins with ?prv where ? is either x,y, Y or Z, or z depending on the type of address you want to generate.

in the case of a deterministic wallet like electrum the relationship is as follows:

seed > master private key > address specific key pairs and addresses.

alternatively: seed > master private key > master public key > public keys and addresses

so if you have the seed you can derive the entire wallet.

[khaled0111]

The whole point of using a watch-only wallet is to monitor your addresses activity and, at the same time, to keep your funds safe by not disclosing your private keys.
As stated above, PK are needed to sign transactions/messages. (If it was possible to sign transactions from a watch-only wallet then anyone would import your public keys and steal your funds).

However, you can use a watch-only wallet to create an unsigned transaction and then you can sign it using the corresponding private keys.

[NotATether]

Thanks for the answers and clarifications everyone.

I'm about to create a watch-only wallet so I can copy my addresses more easily without having to worry about the safety of my private keys. Because private keys are not in the watch only wallet will I not be able to sign a message from it?

no. also when we talk about spending bitcoin we say we sign transactions not messages. messages implies arbitrary content.

For some reason this almost made me think that the message signing process is the same as the transaction signing process, though I got your point that transaction signing is relevant only in the context of spending, I was asking about signed messages. Isn't a transaction signature an ECDSA sig of something? I don't see how the same process can be used to make that and also make arbitrary content.

note there is also such a thing as a master private key which lets you derive all private and public  keys and corresponding addresses. it begins with ?prv where ? is either x,y, Y or Z, or z depending on the type of address you want to generate.

I'm not sure what yprv, zprv and the others you mentioned mean except for xprv which I know is a BIP32 private key. Information about these is scarce so can you tell me what each of these stand for?

[nc50lc]

I'm not sure what yprv, zprv and the others you mentioned mean except for xprv which I know is a BIP32 private key. Information about these is scarce so can you tell me what each of these stand for?

Those are all "BIP32 Root key" or master private key in Electrum.

The first character differs per wallet type :
xprv is for P2PKH or Legacy; and also for MultiSig-P2SH ('1' addresses or '3' MultiSig Addresses)
yprv is for P2WPKH-P2SH or Nested-SegWit ('3' SegWit addresses - if "Y" is upper-case, then the wallet is MultiSig)
zprv is for P2WPKH or Native-SegWit ('bc1' addresses - if "Z" is upper-case, then the wallet is MultiSig):

By the way, you don't need internet to sign a message, just use your offline computer/device to sign a message if you're concerned about your keys' security.

[pooya87]

For some reason this almost made me think that the message signing process is the same as the transaction signing process, though I got your point that transaction signing is relevant only in the context of spending, I was asking about signed messages. Isn't a transaction signature an ECDSA sig of something? I don't see how the same process can be used to make that and also make arbitrary content.

why not? ECDSA is just mathematics where we have a formula and put some variables in it and compute the result. the process is exactly the same for transaction signing, message signing, SSL certificate signatures, in your Apple services like iCloud and a lot more. the only difference is the data that you are signing. in a bitcoin transaction the data is the modified transaction, in message signing it is the modified message both hashed with the same algorithm (SHA256 of SHA256).

I'm not sure what yprv, zprv and the others you mentioned mean except for xprv which I know is a BIP32 private key. Information about these is scarce so can you tell me what each of these stand for?

it is just encoding. you have the same 32 byte private key + 32 byte chaincode + child number + depth which you are encoding. if you use a different version at the beginning you get a different "string" which as @nc50lc is used to indicate the address type that your wallet is supposed to derive from that master key.

[Abdussamad]

yprv,zprv etc. are electrum inventions. they indicate the type of addresses to generate.

https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES#L535

other wallets may or may not support them. there is no bip.

[o_e_l_e_o]

there is no bip.

Can you explain what you mean by this? yprv is explained in BIP49 and zprv is explained in BIP84.

Extended public keys use 0x049d7cb2 to produce a "ypub" prefix, and private keys use 0x049d7878 to produce a "yprv" prefix.

Extended public keys use 0x04b24746 to produce a "zpub" prefix, and private keys use 0x04b2430c to produce a "zprv" prefix.

They are both also registered in SLIP0132, along with their multi-sig equivalents: https://github.com/satoshilabs/slips/blob/master/slip-0132.md

Do you mean that they didn't originally come from a BIP?

[bob123]

If you would be able to sign a message with an watch-only wallet, this would also mean you could sign transactions.
In this case it wouldn't be a watch-only wallet anymore.

The master key can generate all the bitcoin addresses of the wallet, and I think also their public keys, as an address is just a portion of the public key.

The address is created out of the public key.
The public key is derived from the master public key which is then hashed to retrieve the address.

But a signed message needs both the address and private key to work, doesn't it?

You only need the private key to sign a message. But with the private key you also can automatically derive the address.
The public key then is needed to verify the message.

Master private key -> master public key
Master private key -> child private key -> public key -> address
Master public key -> child public key -> address

A watch-only wallet is created using the master public key.

[Abdussamad]

there is no bip.

Can you explain what you mean by this? yprv is explained in BIP49 and zprv is explained in BIP84.

Extended public keys use 0x049d7cb2 to produce a "ypub" prefix, and private keys use 0x049d7878 to produce a "yprv" prefix.

Extended public keys use 0x04b24746 to produce a "zpub" prefix, and private keys use 0x04b2430c to produce a "zprv" prefix.

They are both also registered in SLIP0132, along with their multi-sig equivalents: https://github.com/satoshilabs/slips/blob/master/slip-0132.md

Do you mean that they didn't originally come from a BIP?

TIL! I thought it was an electrum only concoction.

[o_e_l_e_o]

So out of interest, I read in to it a bit more. Looks like the yprv/zprv scheme was originally proposed by Thomas Voegtlin and he implemented it in to Electrum first, and then it was adopted by the wider community and integrated in to the above BIPs. The original discussion regarding it is viewable here: https://bitcoin-development.narkive.com/c7doYh54/proposal-bip32-version-bytes-for-segwit-scripts

TIL.

[NotATether]

So out of interest, I read in to it a bit more. Looks like the yprv/zprv scheme was originally proposed by Thomas Voegtlin and he implemented it in to Electrum first, and then it was adopted by the wider community and integrated in to the above BIPs. The original discussion regarding it is viewable here: https://bitcoin-development.narkive.com/c7doYh54/proposal-bip32-version-bytes-for-segwit-scripts

TIL.

I'm glad they were made into prefixes instead of values in an obscure field that isn't human readable. Just like how bitcoin addresses have a distinct prefix in front of them, for symmetry it's also important for the version master pubic and private keys to be quickly distinguishable by glancing at it without using software, since ultimately, public/private keys and by extension the addresses are derived from them as you guys mentioned.

[pooya87]

I'm glad they were made into prefixes instead of values in an obscure field that isn't human readable. Just like how bitcoin addresses have a distinct prefix in front of them, for symmetry it's also important for the version master pubic and private keys to be quickly distinguishable by glancing at it without using software, since ultimately, public/private keys and by extension the addresses are derived from them as you guys mentioned.

true but the problem is that almost nobody ever uses extended keys to create backups, transfer to another wallet,... instead they either use private keys (simple WIFs) or their mnemonics and neither of these two have any way of telling the wallet what type of address is derived from them with the exception of Electrum mnemonics which are not supported by majority of alternative implementations.

[o_e_l_e_o]

instead they either use private keys (simple WIFs) or their mnemonics

Is that necessarily a bad thing for mnemonics? On the rare occasion I have to use a legacy address because some online service or shop still doesn't support SegWit, I can either simply plug in a hardware wallet or open my airgapped wallet and have it spit out a legacy address without any fuss. It would be much more time consuming to have to create and back up an entire new seed and wallet just to get a legacy address. Similarly, there are some people who regularly use p2pkh, p2sh and p2wpkh addresses, and can do so with a single seed phrase rather than having to back up multiple seed phrases. There will likely be similar situations in the future when the next address type comes along, perhaps a quantum resistant address with Lamport signatures.

[pooya87]

instead they either use private keys (simple WIFs) or their mnemonics

Is that necessarily a bad thing for mnemonics? On the rare occasion I have to use a legacy address because some online service or shop still doesn't support SegWit, I can either simply plug in a hardware wallet or open my airgapped wallet and have it spit out a legacy address without any fuss. It would be much more time consuming to have to create and back up an entire new seed and wallet just to get a legacy address. Similarly, there are some people who regularly use p2pkh, p2sh and p2wpkh addresses, and can do so with a single seed phrase rather than having to back up multiple seed phrases. There will likely be similar situations in the future when the next address type comes along, perhaps a quantum resistant address with Lamport signatures.

you have to think about regular users (the majority) not those who have easier time with the technical aspects of bitcoin. most of them don't even know what P2XX is let alone be capable of making a switch between these different scripts.
so now we have a user that followed the recommendation and created a back up of their BIP39 mnemonic that were created by a wallet that dies (like what happened to multibit) now that they want to recover their funds they also have to dig and figure out what the hell is an address type and all those P2XX stuff then have to figure out how to change the type and recover their actual keys.
from time to time we see some beginner who is scared thinking he lost his bitcoins because he did recover using a mnemonic and the balance was zero!

as for the use case example you mentioned you are already creating another wallet without even knowing it (unless the code you use is broken) since each address uses a different derivation path.
this could also be fixed with a little bit of version meddling. for example if a single byte were to be added to be beginning of a mnemonic (or bigger for a more scalable solution) you could handle 8 different address types: 0bABCDEFGH for example if the H bit was set the wallet creates P2PKH addresses, if G bit was set a P2WPKH and if GH were both set it creates both addresses.
this way you still keep it user friendly and the user can still change their mind and add newer address types to their mnemonic and re-encode it again.
it will also make the lives of wallet developers a lot easier.

[Abdussamad]

a single byte would allow for 256 different address types (2^8).

[pooya87]

a single byte would allow for 256 different address types (2^8).

not if you use it as a "flag". then each bit has a separate meaning and can be combined with other bits. if you use integer values (1, 2, 3,...) then you'll have to define a lot of different cases (1-> x, 2->y, 3->z,... 50->x+y, 60->x+z,...). that makes implementation a nightmare.
in contrast using 0b00000001->x, 0b00000010->y is enough because x+y is 0b00000011 with a simple OR (x|y)