Post your SegWit questions here - open discussion - big week for Bitcoin!

[achow101]

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)).

[Manfred Macx]

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.

[amaclin]

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.

[Manfred Macx]

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?

[TransaDox]

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)

[achow101]

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.

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.

[Manfred Macx]

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.

And here is an example: here is the whole process of signing a transaction.

[X7]

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.

[TransaDox]

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.

Exactly. So one can create a signed hash if the definition is as you describe - a two step process.

This argument is also used for "scriptSig" -

"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.

[achow101]

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.

[TransaDox]

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:
 }

Where "Text" is expected to be an ASCII string and "Sig" is expected to be an MD5 hash of the message represented in hex.

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".

[amaclin]

This seems far from "impossible".

MD5 is not malleable, but ECDSA is.
MD5 is hash-function, but ECDSA is signing

[TransaDox]

This seems far from "impossible".

MD5 is not malleable, but ECDSA is.
MD5 is hash-function, but ECDSA is signing

You need to re-read the post.

Of course. "Malleability" is an umbrella term for multiple issues that affect corner cases. For example. The script is hashed then signed causing a different hash if the instructions are changed but, never the less, yield the same result. The solution to this aspect, I believe, is to hash the final stack instead of the current method.

[amaclin]

You need to re-read the post.

Sorry, too difficult for me to catch all nuances. My English is far from perfect.

Of course. "Malleability" is an umbrella term

First of all, ecdsa malleablity is the abliity to change the signature itself for the same
data without invalidating it by the person who knows the secret or by the "middle-man"

[TransaDox]

Of course. "Malleability" is an umbrella term

First of all, ecdsa malleablity is the abliity to change the signature itself for the same
data without invalidating it by the person who knows the secret or by the "middle-man"

Sure, because distinguishing between  σ = (r,s) and σ'= (r,N − s) is just too hard for bitcoin, eh?  
Ripple uses (r,s) < (r,N − s)?  (r,s):(r,N − s)

[bitdexter]

What is Segwit?

[JayJuanGee]

What is Segwit?

Do you know about the google? 

Here you go:

https://bitcoincore.org/en/2016/01/26/segwit-benefits/

[Manfred Macx]

Sure, because distinguishing between  σ = (r,s) and σ'= (r,N − s) is just too hard for bitcoin, eh?  
Ripple uses (r,s) < (r,N − s)?  (r,s):(r,N − s)

This isn't the only source of malleability. The abandoned BIP62 lists ways in which a Bitcoin transaction is malleable:

• Non-DER encoded ECDSA signatures
• Non-push operations in scriptSig
• Push operations in scriptSig of non-standard size type
• Zero-padded number pushes
• Inherent ECDSA signature malleability
• Superfluous scriptSig operations
• Inputs ignored by scripts
• Sighash flags based masking

[TransaDox]

This isn't the only source of malleability. The abandoned BIP62 lists ways in which a Bitcoin transaction is malleable:

• Non-DER encoded ECDSA signatures
• Non-push operations in scriptSig
• Push operations in scriptSig of non-standard size type
• Zero-padded number pushes
• Inherent ECDSA signature malleability
• Superfluous scriptSig operations
• Inputs ignored by scripts
• Sighash flags based masking

Of course. I have already said it was an "umbrella term" to which amacilin picked one and I specifically gave him a solution to that. I also mentioned  hashing the final stack which would fix:

• Superfluous scriptSig operations
• Inputs ignored by scripts
• Sighash flags based masking
• Non-push operations in scriptSig

The DER encoding is a consensus issue since OpenSSL accepts BER and DER (DER being a subset of BER). Pre-checking before passing to OpenSSL is trivial.

The point is that malleability is an edge case symptom that can be solved without adding a lot more complexity. There is a lot more to this SegWit proposal than we are being told.

[amaclin]

Of course. I have already said it was an "umbrella term" to which amacilin picked one

The owner of private key can create several different valid signatures for the same data needed to sign.
This is also "malleability" and I told you about it ( ...by the person who knows the secret... )
The biggest advantage of segwit is that the txid would not change with different signatures
and can be calculated *before* signing the transaction