Buckle up for today's #DecodingBitcoin post. It's a long one but we promise it's worth your time.
Today we're going to break down how to sign a #bitcoin segwit transaction using a real example from the BIP-143 test vectors (thatโs one of the segwit BIPs!)
๐๐๐ก๐: ๐กโ๐๐ ๐๐ฅ๐๐๐๐๐ ๐๐ ๐๐๐ ๐ ๐ ๐๐๐ค๐๐ก ๐ฃ0 ๐ก๐๐๐๐ ๐๐๐ก๐๐๐ ๐ ๐ ๐ ๐๐๐ ๐๐ ๐กโ๐ ๐ ๐๐๐๐๐๐๐๐ ๐๐๐ ๐๐๐๐๐๐๐๐๐ก ๐๐๐ ๐๐๐๐๐๐ฆ ๐๐๐ ๐ก๐๐๐๐๐๐ก (๐ ๐๐๐ค๐๐ก ๐ฃ1) ๐ก๐๐๐๐ ๐๐๐ก๐๐๐๐ . ๐ป๐๐ค๐๐ฃ๐๐, ๐กโ๐ ๐๐๐๐๐๐๐ ๐๐๐๐๐๐๐ก๐ ๐๐๐ ๐ ๐ก๐๐๐ ๐กโ๐ ๐ ๐๐๐!
The transaction we'll be working with has two inputs. The first is a legacy P2PK inputโwe wonโt be covering that today.
Instead, weโre going to focus on the second input, the P2WPKH (native segwit) one.
Since this example came from one of the BIP-143 test vectors, we know what the final, signed transaction looks like. The goal is to recreate this:
First, we create the base transaction, the transaction without any signatures.
Weโll start with the
- version number
- marker & flag fields (to indicate the tx is segwit)
- locktime
๐ด ๐๐๐ก๐ ๐๐ ๐ ๐๐๐ค๐๐ก ๐ฃ๐ . ๐๐๐๐๐๐ฆ ๐ก๐๐๐๐ ๐๐๐ก๐๐๐๐ : ๐ต๐๐๐๐ข๐ ๐ ๐๐ก ๐๐๐๐ ๐ก ๐๐๐ ๐๐ ๐กโ๐ ๐๐๐๐ข๐ก๐ ๐๐ ๐ ๐๐๐ค๐๐ก (๐๐๐ก๐๐ฃ๐ ๐๐ ๐ค๐๐๐๐๐๐), ๐กโ๐ ๐ก๐๐๐๐ ๐๐๐ก๐๐๐ ๐๐ ๐๐๐ ๐ ๐๐๐๐ ๐๐๐๐๐๐ ๐ ๐๐๐ค๐๐ก.
Hereโs what we have so far:
Letโs add inputs! Recall that all inputs come from existing transactions. That means for each input, we need to find the transaction it came from and get:
1. that transactionโs ID
2. the output index
๐๐ก๐๐ญโ๐ฌ ๐๐ง ๐จ๐ฎ๐ญ๐ฉ๐ฎ๐ญ ๐ข๐ง๐๐๐ฑ?
Every transaction has a list of outputs. The โoutput indexโ is a way to reference a specific output from the list.
We need to ask, "from a transactionโs list of outputs, which one corresponds to the input I care about?โ
For each input, two more things are needed: the ๐ฌ๐๐ซ๐ข๐ฉ๐ญ๐๐ข๐ (placeholder for data required to spend the input), and a ๐ฌ๐๐ช๐ฎ๐๐ง๐๐ ๐ง๐ฎ๐ฆ๐๐๐ซ (usually 0xFFFFFFFF)
After adding all the inputs, the transaction looks like this:
Remember when we said the scriptSig would be a placeholder? Hereโs why those fields are currently empty:
Time to add outputs! For each output, we include the
- amount (in satoshis)
- scriptPubKey: the locking script that defines the rules for how the output can be spent
Things are starting to come together!
A few more things are needed before we can get to signing. First is setting up the ๐ฐ๐ข๐ญ๐ง๐๐ฌ๐ฌ field.
This is where the signature and corresponding public key go for segwit transactions.
The witness field starts off empty. This is different from legacy transactions where signatures are placed directly in the scriptSig field.
The next thing thatโs needed is the ๐ฌ๐๐ซ๐ข๐ฉ๐ญ๐๐จ๐๐.
The scriptCode for a P2WPKH (pay-to-witness-public-key-hash) input is:
๐โ๐๐กโ๐ ๐กโ๐๐ก 20 ๐๐ฆ๐ก๐ ๐๐ข๐๐๐๐ฆ โ๐๐ โ?
๐ธ๐๐๐๐๐๐ ๐ค๐ ๐ ๐๐ค ๐๐๐โ ๐๐ข๐ก๐๐ข๐ก โ๐๐ ๐ ๐ ๐๐๐๐๐ก๐๐ข๐๐พ๐๐ฆ (๐๐ข๐๐๐ ๐๐๐ โ๐๐ค ๐ก๐ ๐ ๐๐๐๐ ๐กโ๐ ๐๐ข๐ก๐๐ข๐ก). ๐ด๐๐ ๐, ๐๐๐๐๐๐ ๐กโ๐๐ก ๐กโ๐ ๐๐๐๐ข๐ก ๐ก๐ ๐๐๐ ๐ก๐๐๐๐ ๐๐๐ก๐๐๐ ๐๐ ๐กโ๐ ๐๐ข๐ก๐๐ข๐ก ๐๐๐๐ ๐๐๐๐กโ๐๐.
๐โ๐ 20 ๐๐ฆ๐ก๐ ๐๐ข๐๐๐๐ฆ โ๐๐ โ ๐๐ ๐๐ฅ๐ก๐๐๐๐ก๐๐ ๐๐๐๐ ๐กโ๐ ๐๐๐๐๐๐ ๐๐๐๐๐๐๐ ๐๐ข๐ก๐๐ข๐ก'๐ ๐ ๐๐๐๐๐ก๐๐ข๐๐พ๐๐ฆ.
Hereโs the ๐ฌ๐๐ซ๐ข๐ฉ๐ญ๐๐จ๐๐ for the example weโre working on:
Lastly, three important hashes are required.
The first is ๐ก๐๐ฌ๐ก๐๐ซ๐๐ฏ๐จ๐ฎ๐ญ๐ฌ. Itโs the double SHA256 hash of all input outpoints (outpoint = the transaction id + output index)
The second is ๐ก๐๐ฌ๐ก๐๐๐ช๐ฎ๐๐ง๐๐, the double SHA256 hash of all input sequence numbers.
The third is ๐ก๐๐ฌ๐ก๐๐ฎ๐ญ๐ฉ๐ฎ๐ญ๐ฌ, the double SHA256 hash of all outputs.
Thatโs everything (finally!). Letโs put it all together into something that can be signed!
When signing a transaction, the spender actually signs a hash of the transaction data, not the entire transaction itself. This hash is called the ๐ฌ๐ข๐ ๐ก๐๐ฌ๐ก.
The data used to create the sighash is called the ๐ฉ๐ซ๐๐ข๐ฆ๐๐ ๐.
For a transaction input, the preimage is made of these items:
The sighash_type indicates which parts of the transaction the signature is committing to.
After hashing the preimage twice with SHA-256, weโre left with the sighash.
At last! Itโs time to do some signing!
There are a few steps for signing a segwit (v0) transaction.
First, the signerโs private key is used to create an ECDSA signature for the sighash.
The resulting signature has two parts, ๐ and ๐ .
In ECDSA, there are actually two valid s values for every signature: a "high" value and a "low" value.
Both are mathematically valid, but bitcoin requires using the low s value to prevent transaction malleability (that means altering a transaction's ID!)
After selecting the low s value, the signature must be encoded into DER format. This is how itโs structured:
And hereโs what the DER encoded signature looks like for our example:
The last step is to add a byte at the end for the sighash type. If we look back at the preimage made earlier we see this example is using SIGHASH_ALL (0x01).
The full code for the signing step looks like this:
Remember the transaction witness field we set space aside for? Itโs now time to put the signature in it ๐
This is how the witness field is structured:
Which works out to be this for our example:
With the completion of the witness field, the transaction is now signed!
This is what the final signed transaction hex looks like broken down:
Bonus: You can use the Bitcoin Core CLI decoderawtransaction command to examine all the parts of the raw transaction hex
* ~ * ~ * ~ * ~ * ~ * ~
If you made it to the end, give yourself a pat on the back. If you enjoyed it, be sure to like this post so we know to make more like it!
* ~ * ~ * ~ * ~ * ~ * ~
This material is from Decoding Bitcoin, your go-to resource for understanding bitcoin, #privacy, and #decentralization.
You can visit 
for the full lesson with all the code examples, as well as more free, interactive content.
For more of a challenge, play chapters 4, 5, and 6 of @Saving Satoshi (
) to learn about public-private key cryptography, digital signatures, and transaction building ๐บ
Hope you learned something new about transaction signing. If you enjoyed this, share it with a friend and donโt forget to follow us, @Bitcoin Dev Project for more content like this.
Thanks for reading!
๐๐๐ก๐: ๐กโ๐๐ ๐๐ฅ๐๐๐๐๐ ๐๐ ๐๐๐ ๐ ๐ ๐๐๐ค๐๐ก ๐ฃ0 ๐ก๐๐๐๐ ๐๐๐ก๐๐๐ ๐ ๐ ๐ ๐๐๐ ๐๐ ๐กโ๐ ๐ ๐๐๐๐๐๐๐๐ ๐๐๐ ๐๐๐๐๐๐๐๐๐ก ๐๐๐ ๐๐๐๐๐๐ฆ ๐๐๐ ๐ก๐๐๐๐๐๐ก (๐ ๐๐๐ค๐๐ก ๐ฃ1) ๐ก๐๐๐๐ ๐๐๐ก๐๐๐๐ . ๐ป๐๐ค๐๐ฃ๐๐, ๐กโ๐ ๐๐๐๐๐๐๐ ๐๐๐๐๐๐๐ก๐ ๐๐๐ ๐ ๐ก๐๐๐ ๐กโ๐ ๐ ๐๐๐!
The transaction we'll be working with has two inputs. The first is a legacy P2PK inputโwe wonโt be covering that today.
Instead, weโre going to focus on the second input, the P2WPKH (native segwit) one.
Since this example came from one of the BIP-143 test vectors, we know what the final, signed transaction looks like. The goal is to recreate this:
First, we create the base transaction, the transaction without any signatures.
Weโll start with the
- version number
- marker & flag fields (to indicate the tx is segwit)
- locktime
๐ด ๐๐๐ก๐ ๐๐ ๐ ๐๐๐ค๐๐ก ๐ฃ๐ . ๐๐๐๐๐๐ฆ ๐ก๐๐๐๐ ๐๐๐ก๐๐๐๐ : ๐ต๐๐๐๐ข๐ ๐ ๐๐ก ๐๐๐๐ ๐ก ๐๐๐ ๐๐ ๐กโ๐ ๐๐๐๐ข๐ก๐ ๐๐ ๐ ๐๐๐ค๐๐ก (๐๐๐ก๐๐ฃ๐ ๐๐ ๐ค๐๐๐๐๐๐), ๐กโ๐ ๐ก๐๐๐๐ ๐๐๐ก๐๐๐ ๐๐ ๐๐๐ ๐ ๐๐๐๐ ๐๐๐๐๐๐ ๐ ๐๐๐ค๐๐ก.
Hereโs what we have so far:
Letโs add inputs! Recall that all inputs come from existing transactions. That means for each input, we need to find the transaction it came from and get:
1. that transactionโs ID
2. the output index
๐๐ก๐๐ญโ๐ฌ ๐๐ง ๐จ๐ฎ๐ญ๐ฉ๐ฎ๐ญ ๐ข๐ง๐๐๐ฑ?
Every transaction has a list of outputs. The โoutput indexโ is a way to reference a specific output from the list.
We need to ask, "from a transactionโs list of outputs, which one corresponds to the input I care about?โ
For each input, two more things are needed: the ๐ฌ๐๐ซ๐ข๐ฉ๐ญ๐๐ข๐ (placeholder for data required to spend the input), and a ๐ฌ๐๐ช๐ฎ๐๐ง๐๐ ๐ง๐ฎ๐ฆ๐๐๐ซ (usually 0xFFFFFFFF)
After adding all the inputs, the transaction looks like this:
Remember when we said the scriptSig would be a placeholder? Hereโs why those fields are currently empty:
Time to add outputs! For each output, we include the
- amount (in satoshis)
- scriptPubKey: the locking script that defines the rules for how the output can be spent
Things are starting to come together!
A few more things are needed before we can get to signing. First is setting up the ๐ฐ๐ข๐ญ๐ง๐๐ฌ๐ฌ field.
This is where the signature and corresponding public key go for segwit transactions.
The witness field starts off empty. This is different from legacy transactions where signatures are placed directly in the scriptSig field.
The next thing thatโs needed is the ๐ฌ๐๐ซ๐ข๐ฉ๐ญ๐๐จ๐๐.
The scriptCode for a P2WPKH (pay-to-witness-public-key-hash) input is:
๐โ๐๐กโ๐ ๐กโ๐๐ก 20 ๐๐ฆ๐ก๐ ๐๐ข๐๐๐๐ฆ โ๐๐ โ?
๐ธ๐๐๐๐๐๐ ๐ค๐ ๐ ๐๐ค ๐๐๐โ ๐๐ข๐ก๐๐ข๐ก โ๐๐ ๐ ๐ ๐๐๐๐๐ก๐๐ข๐๐พ๐๐ฆ (๐๐ข๐๐๐ ๐๐๐ โ๐๐ค ๐ก๐ ๐ ๐๐๐๐ ๐กโ๐ ๐๐ข๐ก๐๐ข๐ก). ๐ด๐๐ ๐, ๐๐๐๐๐๐ ๐กโ๐๐ก ๐กโ๐ ๐๐๐๐ข๐ก ๐ก๐ ๐๐๐ ๐ก๐๐๐๐ ๐๐๐ก๐๐๐ ๐๐ ๐กโ๐ ๐๐ข๐ก๐๐ข๐ก ๐๐๐๐ ๐๐๐๐กโ๐๐.
๐โ๐ 20 ๐๐ฆ๐ก๐ ๐๐ข๐๐๐๐ฆ โ๐๐ โ ๐๐ ๐๐ฅ๐ก๐๐๐๐ก๐๐ ๐๐๐๐ ๐กโ๐ ๐๐๐๐๐๐ ๐๐๐๐๐๐๐ ๐๐ข๐ก๐๐ข๐ก'๐ ๐ ๐๐๐๐๐ก๐๐ข๐๐พ๐๐ฆ.
Hereโs the ๐ฌ๐๐ซ๐ข๐ฉ๐ญ๐๐จ๐๐ for the example weโre working on:
Lastly, three important hashes are required.
The first is ๐ก๐๐ฌ๐ก๐๐ซ๐๐ฏ๐จ๐ฎ๐ญ๐ฌ. Itโs the double SHA256 hash of all input outpoints (outpoint = the transaction id + output index)
The second is ๐ก๐๐ฌ๐ก๐๐๐ช๐ฎ๐๐ง๐๐, the double SHA256 hash of all input sequence numbers.
The third is ๐ก๐๐ฌ๐ก๐๐ฎ๐ญ๐ฉ๐ฎ๐ญ๐ฌ, the double SHA256 hash of all outputs.
Thatโs everything (finally!). Letโs put it all together into something that can be signed!
When signing a transaction, the spender actually signs a hash of the transaction data, not the entire transaction itself. This hash is called the ๐ฌ๐ข๐ ๐ก๐๐ฌ๐ก.
The data used to create the sighash is called the ๐ฉ๐ซ๐๐ข๐ฆ๐๐ ๐.
For a transaction input, the preimage is made of these items:
The sighash_type indicates which parts of the transaction the signature is committing to.
After hashing the preimage twice with SHA-256, weโre left with the sighash.
At last! Itโs time to do some signing!
There are a few steps for signing a segwit (v0) transaction.
First, the signerโs private key is used to create an ECDSA signature for the sighash.
The resulting signature has two parts, ๐ and ๐ .
In ECDSA, there are actually two valid s values for every signature: a "high" value and a "low" value.
Both are mathematically valid, but bitcoin requires using the low s value to prevent transaction malleability (that means altering a transaction's ID!)
After selecting the low s value, the signature must be encoded into DER format. This is how itโs structured:
And hereโs what the DER encoded signature looks like for our example:
The last step is to add a byte at the end for the sighash type. If we look back at the preimage made earlier we see this example is using SIGHASH_ALL (0x01).
The full code for the signing step looks like this:
Remember the transaction witness field we set space aside for? Itโs now time to put the signature in it ๐
This is how the witness field is structured:
Which works out to be this for our example:
With the completion of the witness field, the transaction is now signed!
This is what the final signed transaction hex looks like broken down:
Bonus: You can use the Bitcoin Core CLI decoderawtransaction command to examine all the parts of the raw transaction hex
* ~ * ~ * ~ * ~ * ~ * ~
If you made it to the end, give yourself a pat on the back. If you enjoyed it, be sure to like this post so we know to make more like it!
* ~ * ~ * ~ * ~ * ~ * ~
This material is from Decoding Bitcoin, your go-to resource for understanding bitcoin, #privacy, and #decentralization.
You can visit The Bitcoin Dev Project
Signing Transactions
Saving Satoshi
Saving Satoshi
Explore the mysteries of Satoshi and learn about bitcoin along the way.
Hope you learned something new about transaction signing. If you enjoyed this, share it with a friend and donโt forget to follow us, @Bitcoin Dev Project for more content like this.
Thanks for reading!