How is Public Key extracted from (message, digital signature, address)
up vote
3
down vote
favorite
I'm under the impression that a public key is revealed when you sign a message.
Given these 3 inputs.
P2PKH Address, Digital Signature, Message.
Is the public key exposed?
If so, how do you extract the public key from these 3 inputs?
Also, I'm still a little confused on why no applications do this with bech32 addresses. (I've heard it's because derivation path isn't defined... but will it ever be)?
Thanks!
signature message-signing bech32-address p2pkh
asked Nov 21 at 2:34
Michael Tidwell
184
add a comment |
up vote
3
down vote
favorite
I'm under the impression that a public key is revealed when you sign a message.
Given these 3 inputs.
P2PKH Address, Digital Signature, Message.
Is the public key exposed?
If so, how do you extract the public key from these 3 inputs?
Also, I'm still a little confused on why no applications do this with bech32 addresses. (I've heard it's because derivation path isn't defined... but will it ever be)?
Thanks!
signature message-signing bech32-address p2pkh
asked Nov 21 at 2:34
Michael Tidwell
184
add a comment |
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I'm under the impression that a public key is revealed when you sign a message.
Given these 3 inputs.
P2PKH Address, Digital Signature, Message.
Is the public key exposed?
If so, how do you extract the public key from these 3 inputs?
Also, I'm still a little confused on why no applications do this with bech32 addresses. (I've heard it's because derivation path isn't defined... but will it ever be)?
Thanks!
signature message-signing bech32-address p2pkh
asked Nov 21 at 2:34
Michael Tidwell
184
I'm under the impression that a public key is revealed when you sign a message.
Given these 3 inputs.
P2PKH Address, Digital Signature, Message.
Is the public key exposed?
If so, how do you extract the public key from these 3 inputs?
Also, I'm still a little confused on why no applications do this with bech32 addresses. (I've heard it's because derivation path isn't defined... but will it ever be)?
Thanks!
signature message-signing bech32-address p2pkh
signature message-signing bech32-address p2pkh
asked Nov 21 at 2:34
Michael Tidwell
184
asked Nov 21 at 2:34
Michael Tidwell
184
asked Nov 21 at 2:34
Michael Tidwell
184
asked Nov 21 at 2:34
Michael Tidwell
184
asked Nov 21 at 2:34
Michael Tidwell
184
184
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
6
down vote
accepted
An algorithm called Public Key Recovery exists for ECDSA, which lets you construct the public keys for which a given pair of message and signature would be valid.
To explain the algorithm, remember that ECDSA signatures are pairs (r,s) for which sR = mG + rP. In this equation m is the message hash (which must be a hash of a known message), P is the public key (an elliptic curve point), G is the curve generator point, and R is a point for which R.x mod n = r. n is the curve order.
Rearranging this equation you get rP = sR - mG, or P = (s/r)R - (m/r)G. Thus, it seems we can just compute the public key from the message and the signature. Unfortunately, there can be up to 4 different points R for which R.x mod n = r (in practice, the number is almost always 2).
This technique is used in the message signing, allowing the signature to be verified against just an address, rather than a public key. The verifier in this case recomputes the public key from the message and the signature, converts it to an address, and then compares with the provided address. The address input is still required to prevent people from just giving a signature and message, and then seeing an address and thinking this implies the signature was valid. It must be compared against the expected public key or address to be the case.
The reason this isn't implemented for P2SH or BIP173 addresses is because the "standard" was never extended to incorporate those address styles. There is a proposed new standard (BIP 322) which would cover all types of addresses and more, but isn't widely implemented or used yet. BIP 322 also doesn't use pubkey recovery anymore; it simply uses the Script language and encapsulates a scriptSig/witness to verify against the script that corresponds with the address.
answered Nov 21 at 3:37
Pieter Wuille
44.6k390151
Is this related to the second equation located below here ? P = Inverse(S) * Hash(m) * G + Inverse(S) * R * Qa : ( where R and S are the signature values; Qa is Alice’s public key; m is the transaction data that was signed; G is the elliptic curve generator point )
– skaht
Nov 25 at 23:33
@skaht Yes, that's the same equation written in a different form, and using different symbols. What I'm explaining above is how to compute Qa given R,S, and m.
– Pieter Wuille
Nov 26 at 8:00
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
accepted
An algorithm called Public Key Recovery exists for ECDSA, which lets you construct the public keys for which a given pair of message and signature would be valid.
To explain the algorithm, remember that ECDSA signatures are pairs (r,s) for which sR = mG + rP. In this equation m is the message hash (which must be a hash of a known message), P is the public key (an elliptic curve point), G is the curve generator point, and R is a point for which R.x mod n = r. n is the curve order.
Rearranging this equation you get rP = sR - mG, or P = (s/r)R - (m/r)G. Thus, it seems we can just compute the public key from the message and the signature. Unfortunately, there can be up to 4 different points R for which R.x mod n = r (in practice, the number is almost always 2).
This technique is used in the message signing, allowing the signature to be verified against just an address, rather than a public key. The verifier in this case recomputes the public key from the message and the signature, converts it to an address, and then compares with the provided address. The address input is still required to prevent people from just giving a signature and message, and then seeing an address and thinking this implies the signature was valid. It must be compared against the expected public key or address to be the case.
The reason this isn't implemented for P2SH or BIP173 addresses is because the "standard" was never extended to incorporate those address styles. There is a proposed new standard (BIP 322) which would cover all types of addresses and more, but isn't widely implemented or used yet. BIP 322 also doesn't use pubkey recovery anymore; it simply uses the Script language and encapsulates a scriptSig/witness to verify against the script that corresponds with the address.
answered Nov 21 at 3:37
Pieter Wuille
44.6k390151
Is this related to the second equation located below here ? P = Inverse(S) * Hash(m) * G + Inverse(S) * R * Qa : ( where R and S are the signature values; Qa is Alice’s public key; m is the transaction data that was signed; G is the elliptic curve generator point )
– skaht
Nov 25 at 23:33
@skaht Yes, that's the same equation written in a different form, and using different symbols. What I'm explaining above is how to compute Qa given R,S, and m.
– Pieter Wuille
Nov 26 at 8:00
add a comment |
up vote
6
down vote
accepted
An algorithm called Public Key Recovery exists for ECDSA, which lets you construct the public keys for which a given pair of message and signature would be valid.
To explain the algorithm, remember that ECDSA signatures are pairs (r,s) for which sR = mG + rP. In this equation m is the message hash (which must be a hash of a known message), P is the public key (an elliptic curve point), G is the curve generator point, and R is a point for which R.x mod n = r. n is the curve order.
Rearranging this equation you get rP = sR - mG, or P = (s/r)R - (m/r)G. Thus, it seems we can just compute the public key from the message and the signature. Unfortunately, there can be up to 4 different points R for which R.x mod n = r (in practice, the number is almost always 2).
This technique is used in the message signing, allowing the signature to be verified against just an address, rather than a public key. The verifier in this case recomputes the public key from the message and the signature, converts it to an address, and then compares with the provided address. The address input is still required to prevent people from just giving a signature and message, and then seeing an address and thinking this implies the signature was valid. It must be compared against the expected public key or address to be the case.
The reason this isn't implemented for P2SH or BIP173 addresses is because the "standard" was never extended to incorporate those address styles. There is a proposed new standard (BIP 322) which would cover all types of addresses and more, but isn't widely implemented or used yet. BIP 322 also doesn't use pubkey recovery anymore; it simply uses the Script language and encapsulates a scriptSig/witness to verify against the script that corresponds with the address.
answered Nov 21 at 3:37
Pieter Wuille
44.6k390151
Is this related to the second equation located below here ? P = Inverse(S) * Hash(m) * G + Inverse(S) * R * Qa : ( where R and S are the signature values; Qa is Alice’s public key; m is the transaction data that was signed; G is the elliptic curve generator point )
– skaht
Nov 25 at 23:33
@skaht Yes, that's the same equation written in a different form, and using different symbols. What I'm explaining above is how to compute Qa given R,S, and m.
– Pieter Wuille
Nov 26 at 8:00
add a comment |
up vote
6
down vote
accepted
up vote
6
down vote
accepted
An algorithm called Public Key Recovery exists for ECDSA, which lets you construct the public keys for which a given pair of message and signature would be valid.
To explain the algorithm, remember that ECDSA signatures are pairs (r,s) for which sR = mG + rP. In this equation m is the message hash (which must be a hash of a known message), P is the public key (an elliptic curve point), G is the curve generator point, and R is a point for which R.x mod n = r. n is the curve order.
Rearranging this equation you get rP = sR - mG, or P = (s/r)R - (m/r)G. Thus, it seems we can just compute the public key from the message and the signature. Unfortunately, there can be up to 4 different points R for which R.x mod n = r (in practice, the number is almost always 2).
This technique is used in the message signing, allowing the signature to be verified against just an address, rather than a public key. The verifier in this case recomputes the public key from the message and the signature, converts it to an address, and then compares with the provided address. The address input is still required to prevent people from just giving a signature and message, and then seeing an address and thinking this implies the signature was valid. It must be compared against the expected public key or address to be the case.
The reason this isn't implemented for P2SH or BIP173 addresses is because the "standard" was never extended to incorporate those address styles. There is a proposed new standard (BIP 322) which would cover all types of addresses and more, but isn't widely implemented or used yet. BIP 322 also doesn't use pubkey recovery anymore; it simply uses the Script language and encapsulates a scriptSig/witness to verify against the script that corresponds with the address.
answered Nov 21 at 3:37
Pieter Wuille
44.6k390151
An algorithm called Public Key Recovery exists for ECDSA, which lets you construct the public keys for which a given pair of message and signature would be valid.
To explain the algorithm, remember that ECDSA signatures are pairs (r,s) for which sR = mG + rP. In this equation m is the message hash (which must be a hash of a known message), P is the public key (an elliptic curve point), G is the curve generator point, and R is a point for which R.x mod n = r. n is the curve order.
Rearranging this equation you get rP = sR - mG, or P = (s/r)R - (m/r)G. Thus, it seems we can just compute the public key from the message and the signature. Unfortunately, there can be up to 4 different points R for which R.x mod n = r (in practice, the number is almost always 2).
This technique is used in the message signing, allowing the signature to be verified against just an address, rather than a public key. The verifier in this case recomputes the public key from the message and the signature, converts it to an address, and then compares with the provided address. The address input is still required to prevent people from just giving a signature and message, and then seeing an address and thinking this implies the signature was valid. It must be compared against the expected public key or address to be the case.
The reason this isn't implemented for P2SH or BIP173 addresses is because the "standard" was never extended to incorporate those address styles. There is a proposed new standard (BIP 322) which would cover all types of addresses and more, but isn't widely implemented or used yet. BIP 322 also doesn't use pubkey recovery anymore; it simply uses the Script language and encapsulates a scriptSig/witness to verify against the script that corresponds with the address.
answered Nov 21 at 3:37
Pieter Wuille
44.6k390151
answered Nov 21 at 3:37
Pieter Wuille
44.6k390151
answered Nov 21 at 3:37
Pieter Wuille
44.6k390151
answered Nov 21 at 3:37
Pieter Wuille
44.6k390151
44.6k390151
Is this related to the second equation located below here ? P = Inverse(S) * Hash(m) * G + Inverse(S) * R * Qa : ( where R and S are the signature values; Qa is Alice’s public key; m is the transaction data that was signed; G is the elliptic curve generator point )
– skaht
Nov 25 at 23:33
@skaht Yes, that's the same equation written in a different form, and using different symbols. What I'm explaining above is how to compute Qa given R,S, and m.
– Pieter Wuille
Nov 26 at 8:00
add a comment |
Is this related to the second equation located below here ? P = Inverse(S) * Hash(m) * G + Inverse(S) * R * Qa : ( where R and S are the signature values; Qa is Alice’s public key; m is the transaction data that was signed; G is the elliptic curve generator point )
– skaht
Nov 25 at 23:33
@skaht Yes, that's the same equation written in a different form, and using different symbols. What I'm explaining above is how to compute Qa given R,S, and m.
– Pieter Wuille
Nov 26 at 8:00
Is this related to the second equation located below here ? P = Inverse(S) * Hash(m) * G + Inverse(S) * R * Qa : ( where R and S are the signature values; Qa is Alice’s public key; m is the transaction data that was signed; G is the elliptic curve generator point )
– skaht
Nov 25 at 23:33
Is this related to the second equation located below here ? P = Inverse(S) * Hash(m) * G + Inverse(S) * R * Qa : ( where R and S are the signature values; Qa is Alice’s public key; m is the transaction data that was signed; G is the elliptic curve generator point )
– skaht
Nov 25 at 23:33
@skaht Yes, that's the same equation written in a different form, and using different symbols. What I'm explaining above is how to compute Qa given R,S, and m.
– Pieter Wuille
Nov 26 at 8:00
@skaht Yes, that's the same equation written in a different form, and using different symbols. What I'm explaining above is how to compute Qa given R,S, and m.
– Pieter Wuille
Nov 26 at 8:00
add a comment |
Thanks for contributing an answer to Bitcoin Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fbitcoin.stackexchange.com%2fquestions%2f81232%2fhow-is-public-key-extracted-from-message-digital-signature-address%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
