This seems far from "impossible".
MD5 is not malleable, but ECDSA is.MD5 is hash-function, but ECDSA is signing
Topic: Post your SegWit questions here - open discussion - big week for Bitcoin! - page 27. (Read 84847 times)
December 21, 2016, 11:54:08 AM
MD5 is hash-function, but ECDSA is signing
December 21, 2016, 11:42:47 AM
That message cannot include the signature itself because the signature does not exist yet. Including the signature changes the message, thus changing the signature. Thus it is impossible for a signature to sign itself as doing so will inherently change the signature.
OK. Lets consider a trivial example/case.....Let our message be a terse one of:
Code:
{
Sig:
Text:
}1: We create a message
Code:
{Sig: 00000000000000000000000000000000,Text:"A text Message"}2. We now find the MD5 of the entire message which gives us C9D4C59A1FEBA4D1BFE1ECE1EE7269B0. (I've included the brackets and quotes just because of copy and paste)
3. We insert the code back into the message and send - yielding
Code:
{Sig: C9D4C59A1FEBA4D1BFE1ECE1EE7269B0,Text:"A text Message"}To check the sig we simply replace the sig field with zeros as before, calculate the MD5, and check against the original value in the sig field.
This seems far from "impossible".
December 21, 2016, 07:48:34 AM
Exactly. So one can create a signed hash if the definition is as you describe - a two step process.
The second signature is not the same as the first signature, it is a different signature. If you included both signatures, then the second signature can be malleated because it did not sign itself. The first signature cannot be malleated.Other signing protocols do exactly this by signing messages with a "placeholder" field and then inserting the hash afterwards.
That is what Bitcoin does too. The output script is put in the scriptsig for signing.I don't think you understand how signing works. The signature is generated from the message (in this case, the hash of the unsigned transaction serialized in a certain way). That message cannot include the signature itself because the signature does not exist yet. Including the signature changes the message, thus changing the signature. Thus it is impossible for a signature to sign itself as doing so will inherently change the signature.
December 21, 2016, 06:21:49 AM
I keep seeing the main justification for SegWit being that it solved the sighash problem, where it ends with a hand-wave of "The signature script contains the secp256k1 signature, which can’t sign itself"
Can someone explain to me why it can't sign itself? (preferably with an example)
Once the signature is created, if you were to include it in the message and sign it again, you would have a different signature. Having the signature in the message always changes the resulting signature so it can never sign itself.Can someone explain to me why it can't sign itself? (preferably with an example)
This argument is also used for "scriptSig" -
Quote
"While signing the whole scriptSig would be impossible - the signature would be signing itself"
. Other signing protocols do exactly this by signing messages with a "placeholder" field and then inserting the hash afterwards.
December 21, 2016, 05:24:09 AM
The sheer amount of time and money being spent by a few bad actors in attempts to 'block' SegWit has been mind numbing.
Hoping we emerge out the drama relatively unscathed, it doesn't make sense that anyone who wants a "bigger block" would barricade the potential which SegWit offers. Unless emotions and pride are in the way, or ulterior motives are present.
Hoping we emerge out the drama relatively unscathed, it doesn't make sense that anyone who wants a "bigger block" would barricade the potential which SegWit offers. Unless emotions and pride are in the way, or ulterior motives are present.
December 21, 2016, 03:16:56 AM
The scriptCode is there for defining what is actually done in validation of the input. It is there to explicitly define what validation is happening. Since P2WPKH validation is basically the same as P2PKH, the P2PKH script is used as the scriptCode.
I guess that makes sense. Thank you.
I keep seeing the main justification for SegWit being that it solved the sighash problem, where it ends with a hand-wave of "The signature script contains the secp256k1 signature, which can’t sign itself"
Can someone explain to me why it can't sign itself? (preferably with an example)
A signature cannot sign itself because the signature does not exist to be signed until it is created. Signatures sign the hash of the message. The message is the unsigned transaction. Once the signature is created, if you were to include it in the message and sign it again, you would have a different signature. Having the signature in the message always changes the resulting signature so it can never sign itself.Can someone explain to me why it can't sign itself? (preferably with an example)
And here is an example: here is the whole process of signing a transaction.
December 20, 2016, 11:10:31 AM
P2WPKH program is identified by an output containing 0{20-byte-public-key-hash}. The spending transaction witness must contain the proper key which hashes to the 20 byte hash specified in the output. This is different than the regular scriptPubKey format used so far (1976a914{pkh}88ac is not necessary anymore).
But, when we want to hash the P2WPKH transaction for signing, we suddenly prefix the 20 byte pkh from output with 19761914 and suffix it with 88ac. Why do we do this? Why not just use the 20 byte pkh? If we don't use the old srcriptPubKey format for redeeming transactions why do we use it in hashing?
The scriptCode is there for defining what is actually done in validation of the input. It is there to explicitly define what validation is happening. Since P2WPKH validation is basically the same as P2PKH, the P2PKH script is used as the scriptCode.But, when we want to hash the P2WPKH transaction for signing, we suddenly prefix the 20 byte pkh from output with 19761914 and suffix it with 88ac. Why do we do this? Why not just use the 20 byte pkh? If we don't use the old srcriptPubKey format for redeeming transactions why do we use it in hashing?
I keep seeing the main justification for SegWit being that it solved the sighash problem, where it ends with a hand-wave of "The signature script contains the secp256k1 signature, which can’t sign itself"
Can someone explain to me why it can't sign itself? (preferably with an example)
A signature cannot sign itself because the signature does not exist to be signed until it is created. Signatures sign the hash of the message. The message is the unsigned transaction. Once the signature is created, if you were to include it in the message and sign it again, you would have a different signature. Having the signature in the message always changes the resulting signature so it can never sign itself. Can someone explain to me why it can't sign itself? (preferably with an example)
December 20, 2016, 10:31:12 AM
I keep seeing the main justification for SegWit being that it solved the sighash problem, where it ends with a hand-wave of "The signature script contains the secp256k1 signature, which can’t sign itself"
Can someone explain to me why it can't sign itself? (preferably with an example)
Can someone explain to me why it can't sign itself? (preferably with an example)
December 20, 2016, 05:37:53 AM
P2WPKH program is identified by an output containing 0{20-byte-public-key-hash}. The spending transaction witness must contain the proper key which hashes to the 20 byte hash specified in the output. This is different than the regular scriptPubKey format used so far (1976a914{pkh}88ac is not necessary anymore).
But, when we want to hash the P2WPKH transaction for signing, we suddenly prefix the 20 byte pkh from output with 19761914 and suffix it with 88ac. Why do we do this? Why not just use the 20 byte pkh? If we don't use the old srcriptPubKey format for redeeming transactions why do we use it in hashing?
But, when we want to hash the P2WPKH transaction for signing, we suddenly prefix the 20 byte pkh from output with 19761914 and suffix it with 88ac. Why do we do this? Why not just use the 20 byte pkh? If we don't use the old srcriptPubKey format for redeeming transactions why do we use it in hashing?
December 20, 2016, 03:50:30 AM
I understand that. I guess my question was imprecise. I was wondering why do we need the 0x1976a914{20-byte-pubkey-hash}88ac part.
This is the id of funds receiver. December 20, 2016, 03:31:19 AM
I'm reading BIP143 about new transaction digest algorithm. In Specification item 5 is scriptCode of the input and for P2WPKH it says 'For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac'. For a script to be P2WPKH it has to have output '0 {20-byte-hash}'. Am I to understand that this new digest algorithm takes this 20-byte-hash and wraps it into script code before hashing?
No. The 20-byte-hash in the output script is the same as the 20-byte-hash in the scriptCode. It is the ripemd160(sha256(pubkey)).I understand that. I guess my question was imprecise. I was wondering why do we need the 0x1976a914{20-byte-pubkey-hash}88ac part.
December 19, 2016, 11:06:43 AM
I'm reading BIP143 about new transaction digest algorithm. In Specification item 5 is scriptCode of the input and for P2WPKH it says 'For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac'. For a script to be P2WPKH it has to have output '0 {20-byte-hash}'. Am I to understand that this new digest algorithm takes this 20-byte-hash and wraps it into script code before hashing?
No. The 20-byte-hash in the output script is the same as the 20-byte-hash in the scriptCode. It is the ripemd160(sha256(pubkey)). December 19, 2016, 09:55:43 AM
I'm reading BIP143 about new transaction digest algorithm. In Specification item 5 is scriptCode of the input and for P2WPKH it says 'For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac'. For a script to be P2WPKH it has to have output '0 {20-byte-hash}'. Am I to understand that this new digest algorithm takes this 20-byte-hash and wraps it into script code before hashing?
December 15, 2016, 05:05:45 PM
Any actual questions, do step right up
December 15, 2016, 05:02:28 PM
I believe it's time to speak honestly about Segwit, which I do not support, for different reasons. No troll. Flame away. Kano is a legit developer of mining software who has also raised valid concerns about the code.
Kano raised invalid concerns, just like the rest of your concerns, not valid.
It seems like a huge number of people are saying: "I don't understand the point of fixing signature malleability, or why quadratic sighash scaling is an issue, so, why?"
This is incredibly arrogant, and ignorant. And I don't normally listen to anything that people say who are too arrogant to fix their own ignorance. Do you?
Kano raised concerns. You can allay or confirm those concerns or just not answer. I would prefer the former but would be just as happy with the latter.
December 14, 2016, 01:03:00 PM
I believe it's time to speak honestly about Segwit, which I do not support, for different reasons. No troll. Flame away. Kano is a legit developer of mining software who has also raised valid concerns about the code.
Kano raised invalid concerns, just like the rest of your concerns, not valid.
It seems like a huge number of people are saying: "I don't understand the point of fixing signature malleability, or why quadratic sighash scaling is an issue, so, why?"
This is incredibly arrogant, and ignorant. And I don't normally listen to anything that people say who are too arrogant to fix their own ignorance. Do you?
Damn.... You do realize this is a q&a thread? Maybe it's a good idea to retract those claws so people can ask some "stupid questions". Adoption isn't exactly going swimmingly.
December 14, 2016, 09:58:27 AM
Is BIP142, new segwit address format, abandoned?
It has been deferred, meaning that it is abandoned for now but likely that it will be picked up again later.Also, are CLTV and CSV treated as P2WS now?
CLTV and CSV are OP codes. They are part of scripts, so they can be used in any p2sh address. Anything that was p2sh can become p2wsh. December 14, 2016, 09:04:04 AM
Is BIP142, new segwit address format, abandoned? Also, are CLTV and CSV treated as P2WS now?
December 14, 2016, 04:04:11 AM
First of all, the new hashing algorithm is for sighashing, so it has no effect on malleability. That new hashing algorithm is to fix quadratic sighashing.
It is possible to fix malleability be redefining txid hashing to ignore everything in the scriptsig. However this would be a hard fork and break every single unconfirmed transaction at the time of said fork.
It is possible to fix malleability be redefining txid hashing to ignore everything in the scriptsig. However this would be a hard fork and break every single unconfirmed transaction at the time of said fork.
Thank you. I figured out later that my question makes no sense
December 13, 2016, 10:41:41 AM
My first question is, would it be enough to just change the hashing algorithm (BIP143) to fix this instead of introducing the witness field?
First of all, the new hashing algorithm is for sighashing, so it has no effect on malleability. That new hashing algorithm is to fix quadratic sighashing.It is possible to fix malleability be redefining txid hashing to ignore everything in the scriptsig. However this would be a hard fork and break every single unconfirmed transaction at the time of said fork.
Jump to: