Something worth noting at this point is that new address types take what seems like forever to be proposed. For example the earliest mentions of segwit P2WSH and P2WPKH I found in the bitcoin-dev mailing list are in January 2016, but they weren't merged into the codebase until December 2017, two years later: https://github.com/bitcoin/bitcoin/commit/940a21932ba769ba5829cba713579db84f96d2f8. So for using a single byte to represent address types with flags, 3 bits are already occupied, but it leaves 5 bits which will get used up slowly as new BIPs are made.
6 or so years passed, measuring from the beginning of bitcoin core to January 2016, with only one address type in use. If we assume new address types are added every 6 years then extrapolating, I'd say that a single byte will last us 18 years from today before we run out of bits for address types.
We'd have to add an extra byte every 24 years to get more flags. I assume address types are created in the same time frame as the one between P2SH and P2WSH/P2WPKH.
Topic: Can a watch-only wallet sign messages from its addresses? (Read 347 times)
~
what's the advantage of doing bitwise operations like these on the version bits? seems like a poor use of space to me.
what's the advantage of doing bitwise operations like these on the version bits? seems like a poor use of space to me.
mainly to combine different options together. they are used everywhere in programming and in bitcoin. for example each transaction has a "flag" indicating its sighash type which can be combined by another bit called AnyoneCanPay. or the P2P protocol has a service "flag" that indicates the options that the node supports (full node, UTXO, bloom filters, witness, XThin and pruned).
the advantage is making what o_e_l_e_o said easier. a quick look at the bits in such a version tells the wallet right away which type of addresses it should derive from the mnemonic. this is something Electrum partially uses but only for 4 types (SegWit, legacy, SegWit-2FA and legacy-2FA) and is not that scalable since scaling it to more bytes would make the brute force operation that is performed to find the mnemonic a lot harder and can potentially end up taking minutes for the user to generate a new wallet!
just because you can store 256 versions/address types doesn't mean you have to use all of them today. you can use the ones you need to and leave the rest for future expansion. or use a smaller number of bits for the version/address type like 4 or 6 bits.
electrum actually uses a system where the first 4 bits tell you how long the version number is. it's very flexible and perhaps overkill.
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)
what's the advantage of doing bitwise operations like these on the version bits? seems like a poor use of space to me.
electrum actually uses a system where the first 4 bits tell you how long the version number is. it's very flexible and perhaps overkill.
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)
what's the advantage of doing bitwise operations like these on the version bits? seems like a poor use of space to me.
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)
a single byte would allow for 256 different address types (2^8).
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.
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. 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.
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.
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.
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.
TIL.
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.
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 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.
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.
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.
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?
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.
https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES#L535
other wallets may or may not support them. there is no bip.
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).Quote
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. 
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.
Thanks for the answers and clarifications everyone.
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.
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?
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?
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.
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.
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.
Quote
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.
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.
Jump to: