<p>This is an excellent answer by amaclin and Wizard of Ozzie. I'd just like to add some more detail for the Wizard of Ozzie's transaction at <a href="https://blockchain.info/tx/211b8fb30990632751a83d1dc4f0323ff7d2fd3cad88084de13c9be2ae1c6426" rel="nofollow noreferrer">blockchain.info</a>.</p>
<ol>
<li><p>The correct input to the signature process for this transaction is</p>
<pre><code> 01000000
 01
 be66e10da854e7aea9338c1f91cd489768d1d6d7189f586d7a3613f2a24d5396
 00000000
 19 76 a9 14 dd6cce9f255a8cc17bda8ba0373df8e861cb866e 88 ac
 ffffffff
 01
 23ce010000000000
 19 76 a9 14 2bc89c2702e0e618db7d59eb5ce2f0f147b40754 88 ac
 00000000
 01000000
</code></pre>
</li>
<li><p>The double-SHA256 hash of this is computed by <code>bx</code> as</p>
<pre><code> d304448dff517bcf677cd36f3491e9ef2ccfdf40fb63af5782d9b768640af130
</code></pre>
</li>
</ol>
<p>but this is written in &quot;reverse&quot; order for whatever peculiar historical reason (I've heard it was to be compatible with M*soft CRAPi). So when using this with the <code>sign(key, digest)</code> in most sensible crypto toolkits you may need to reverse the hash value to the &quot;proper&quot; order for <code>SHA256(SHA256(m))</code></p>
<pre><code>30f10a6468b7d98257af63fb40dfcf2cefe991346fd37c67cf7b51ff8d4404d3
</code></pre>
<ol start="3">
<li><p>The above input data will indeed validate against the signature given in the actual blockchain transaction</p>
<pre><code>  3045022100da43201760bda697222002f56266bf65023fef2094519e13077f777baed553b102205ce35d05eabda58cd50a67977a65706347cc25ef43153e309ff210a134722e9e
</code></pre>
</li>
</ol>
<p>using the given public key</p>
<pre><code>042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9
</code></pre>
<ol start="4">
<li><p>To generate a reproducible signature over the same data, the following signature has been made by the deterministic method of <a href="https://www.rfc-editor.org/rfc/rfc6979" rel="nofollow noreferrer">RFC6979</a>.</p>
<pre><code> 30450220587ce0cf0252e2db3a7c3c91b355aa8f3385e128227cd8727c5f7777877ad772022100edc508b7c14891ed15ab38c687019d7ebaf5c12908cf21a83e8ae57e8c47e95c
</code></pre>
</li>
</ol>
<p>using the matching private key provided by Wizard of Ozzie</p>
<pre><code>0ecd20654c2e2be708495853e8da35c664247040c00bd10b9b13e5e86e6a808d
</code></pre>
<p>This signature also validates over the given data using the public key and should be reproducible.</p>

CC BY-SA 3.0
2016-02-12T07:03:08.710Z
2016-02-12T09:14:58.870Z
2021-10-07T07:34:52.683Z
David I
<p><strong>Step-by-step description:</strong></p>

<p>We start creating a new transaction which we hash and sign.</p>

<ol>
<li>Add four-byte version field: <code>01000000</code></li>
<li>One-byte varint specifying the number of inputs: <code>01</code></li>
<li>32-byte hash of the transaction from which we want to redeem an output (reverse order): <code>be66e10da854e7aea9338c1f91cd489768d1d6d7189f586d7a3613f2a24d5396</code></li>
<li>Four-byte field denoting the output index we want to redeem from the transaction with the above hash (counting from zero): <code>00000000</code></li>
<li>Now comes the scriptSig. For the purpose of signing the transaction, this is temporarily filled with the scriptPubKey of the output we want to redeem. First we write a one-byte varint which denotes the length of the scriptSig (0x19 = 25 bytes): <code>19</code></li>
<li>Then we write the actual scriptSig (which is the scriptPubKey of the output we want to redeem): <code>76 a9 14 dd6cce9f255a8cc17bda8ba0373df8e861cb866e 88 ac</code> (look to the bottom line line on <a href="https://blockchain.info/tx/96534da2f213367a6d589f18d7d6d1689748cd911f8c33a9aee754a80de166be?show_adv=true" rel="noreferrer">https://blockchain.info/tx/96534da2f213367a6d589f18d7d6d1689748cd911f8c33a9aee754a80de166be?show_adv=true</a> )</li>
<li>Then we write a four-byte field denoting the sequence. This is currently always set to 0xffffffff: <code>ffffffff</code></li>
<li>Next comes a one-byte varint containing the number of outputs in our new transaction. We will set this to 1 in this example: <code>01</code></li>
<li>We then write an 8-byte field (64 bit integer, little-endian) containing the amount we want to redeem from the specified output. I will set this to the total amount available in the output minus a fee of 0.0001 BTC (128307 - 10000): <code>23ce010000000000</code></li>
<li>Then we start writing our transaction's output. We start with a one-byte varint denoting the length of the output script (0x19 or 25 bytes): <code>19</code></li>
<li>Then the actual output script: <code>76 a9 14 a2fd2e039a86dbcf0e1a664729e09e8007f89510 88 ac</code> ( this is transferring funds back to address 1FromKBPAS8MWsk1Yv1Yiu8rJbjfVioBHc )</li>
<li>Then we write the four-byte "lock time" field: <code>00000000</code></li>
<li>And at last, we write a four-byte "hash code type" (1 in our case): <code>01000000</code></li>
</ol>

<p>OK, the result is</p>

<pre><code>01000000
01
be66e10da854e7aea9338c1f91cd489768d1d6d7189f586d7a3613f2a24d5396
00000000
19 76 a9 14 dd6cce9f255a8cc17bda8ba0373df8e861cb866e 88 ac
ffffffff
01
23ce010000000000
19 76 a9 14 a2fd2e039a86dbcf0e1a664729e09e8007f89510 88 ac
00000000
01000000
</code></pre>

<ol start="14">
<li><p>Now we double-SHA256 hash this entire structure, which yields the hash <code>1cde0239b55717cca8003104abc2ec2673d4f6fabea0b74351940e382e88486f</code></p></li>
<li><p>Now we should create ECDSA signature... 
<code>1MBngSqZbMydscpzSoehjP8kznMaHAzh9y</code> is a brainwallet of <em>"mrbubbymrbubbymrbubby!"</em>, which just happens to encode an address starting in <em>'MB'</em> (making linking the 2 quite easy; see @WizardOfAussie comment below for phrase origins). 
Private key in WIF: <code>5HvofFG7K1e2aeWESm5pbCzRHtCSiZNbfLYXBvxyA57DhKHV4U3</code> </p></li>
</ol>

<p>In hex, the private key is <code>0ecd20654c2e2be708495853e8da35c664247040c00bd10b9b13e5e86e6a808d</code>. There is a sign (key, digest) method in every crypto lib. It will return an array of bytes. This array will be no more than 72 bytes, and start with hex code 30. Lets imagine that the signature is <code>3046022100cf4d7571dd47a4d47f5cb767d54d6702530a3555726b27b6ac56117f5e7808fe0221008cbb42233bb04d7f28a715cf7c938e238afde90207e9d103dd9018e12cb7180e</code>
 To this signature we append the one-byte hash code type: <code>01</code>. The public key for 1MBngSqZbMydscpzSoehjP8kznMaHAzh9y is: <code>042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9</code></p>

<ol start="16">
<li>We construct the final scriptSig by concatenating: &lt;One-byte script OPCODE containing the length of the DER-encoded signature plus the one-byte hash code type&gt;|&lt; The actual DER-encoded signature plus the one-byte hash code type&gt;|&lt; One-byte script OPCODE containing the length of the public key&gt;|&lt;The actual public key&gt;</li>
</ol>

<p>scriptSig will be</p>

<pre><code>49 3046022100cf4d7571dd47a4d47f5cb767d54d6702530a3555726b27b6ac56117f5e7808fe0221008cbb42233bb04d7f28a715cf7c938e238afde90207e9d103dd9018e12cb7180e 01
41 042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9
</code></pre>

<p>first line is 'push signature concatenated with 01', second line is 'push pubkey'. The length of scriptSig is 140 bytes (0x8c in hex)</p>

<ol start="17">
<li><p>We then replace the one-byte, varint length-field from step 5 with the length of the data from step 16. The length is 140 bytes, or 0x8C bytes: <code>8c</code></p></li>
<li><p>And we replace the actual scriptSig with the data structure constructed in step 16. </p></li>
<li><p>We finish off by <em>removing</em> the four-byte hash code type we added in step 13, and we end up with the following stream of bytes, which is the final transaction:</p>

<p>01000000
01
be66e10da854e7aea9338c1f91cd489768d1d6d7189f586d7a3613f2a24d5396
00000000
8c 
49 3046022100cf4d7571dd47a4d47f5cb767d54d6702530a3555726b27b6ac56117f5e7808fe0221008cbb42233bb04d7f28a715cf7c938e238afde90207e9d103dd9018e12cb7180e 01
41 042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9
ffffffff
01
23ce010000000000
19 76 a9 14 a2fd2e039a86dbcf0e1a664729e09e8007f89510 88 ac
00000000</p></li>
</ol>

CC BY-SA 3.0
2014-11-24T14:37:15.173Z
Isn't this the steps outlined in the link in the question? I don't this this qualifies for the bounty. @wizardofozzie one thing you have to understand about bitcoin is that testing transactions is unlike any other computer program in history: it is impossible to replicate the same situation twice as is normally the case with testing. ie you can never go back a re-run the exact same situation again.
T9b
CC BY-SA 3.0
2014-11-24T14:53:19.080Z
I do not pretend for bounty. I've just answered a question. And yes, most of my answer is pure copy-paste. May be very small additions. English is not my native language and it is hard for me to write the whole answer myself :)
amaclin
CC BY-SA 3.0
2014-11-25T09:22:31.910Z
I understand now! @amaclin if you want the private keys to edit your answer I can provide it (or I can edit the answer and give the privkey). Fyi it was the DER encoding (the part starting with a 0x30 byte) which I couldn't for the life of me place. I knew there was the 130 char public key starting with 0x04 within the byte array but I couldn't place the first part. I do understand it's going to be signed differently each time (one would hope!) but this is exactly the clarification I needed. I'll likely have to wait until I'm not using the iOS app to award the bounty but amaclin thank you!
Wizard Of Ozzie
CC BY-SA 3.0
2014-11-25T09:28:47.187Z
You should not publish your private keys. You even should not send me your keys (my email is in profile). I think that my answer is full enough, nobody needs that the result been correct transaction existing in blockchain.
amaclin
CC BY-SA 3.0
2014-11-28T10:08:32.627Z
I appreciate what you're getting at (and the fabulous answer!) but the addresses are not holding BTC. The whole point of this was to have a canonical answer which is not testnet or regtest or abstract. So I'm going to edit your answer as I've successfully signed the txn and transmitted it. https://blockchain.info/tx/211b8fb30990632751a83d1dc4f0323ff7d2fd3cad88084de13c9be2ae1c6426
Wizard Of Ozzie
CC BY-SA 3.0
2014-11-28T10:18:19.697Z
I'll add an answer outlining the process using sx tools but for those interested the brainwallet for 1MB... is "mrbubbymrbubbymrbubby!" (no quotes) => 1MBngSqZbMydscpzSoehjP8kznMaHAzh9y ... in case you're wondering it's what the neighbor yells each night to call her cat. It just so happens to hash to 1MB :)
Wizard Of Ozzie
CC BY-SA 3.0
2014-11-28T11:09:38.313Z
Waiting for your next question: how to redeem two outputs in one tx (how to create & sign transaction with more than one input)
amaclin
CC BY-SA 3.0
2015-01-05T02:26:17.673Z
@amaclin Found this AWESOME reference; this blog is unbelievably good for visual ppl like myself... http://www.royalforkblog.com/2014/11/20/txn-demo/?#the-ins-and-outs-of-transactions
Wizard Of Ozzie
CC BY-SA 3.0
2017-12-20T18:47:18.390Z
This is great! However, how is the raw transaction constructed when there are more than one input / output?
user2298995
CC BY-SA 4.0
2019-03-01T08:27:51.283Z
Is there a bip that describes the above?
Malone
CC BY-SA 4.0
2019-11-28T20:32:43.627Z
It's great post. Thanks. I wrote some code based on your great answer but my code doesn't run. Could you help take a look at https://bitcoin.stackexchange.com/questions/92005/verify-bitcoin-transaction ? Thanks a lot.
YongJiang Zhang
CC BY-SA 3.0
2014-11-24T11:33:25.957Z
2017-02-19T21:37:43.760Z
2017-02-19T21:37:43.760Z
amaclin
<p>I am looking, specifically, for a step by step example transaction of sending Bitcoin which uses an <em>actual transaction</em> (<a href="https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx">How To Redeem A Basic Txn</a>, from a few years back, does a great job of outlining most steps of sending a raw txn but <a href="http://blockexplorer.com/tx/f2b3eb2deb76566e7324307cd47c35eeb88413f971d88519859b1834307ecfec" rel="noreferrer">does not use a real TxID</a>).</p>

<p>I have played around with both the Python pybitcointools library, the <a href="http://sx.dyne.org" rel="noreferrer">SX library</a> and JSON output from the Bitcoin Core client (Bitcoin-QT, Bitcoin-cli, Bitcoin daemon) but have yet to find an actual step by step guide using raw transaction output (single input / single output Bitcoin txn, ie not multisig). </p>

<p>Hopefully the bounty will bring a step by step example transaction (with private keys for the sending address) will bring an answer showing how it's done and, specifically:</p>

<ul>
<li>how the ScriptPubKey element fits into the raw txn </li>
<li>how the ScriptSig element fits into the raw txn</li>
<li>how the txn is signed (with DER encoding).</li>
</ul>

<p>EDIT: I think the best resource is <a href="http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html" rel="noreferrer">Ken Shirriff's <em>Bitcoins the hard way: Using the raw Bitcoin protocol</em></a>, but again, there's no single source online that answers my question without skimming past areas like scriptPubKey, signing etc.</p>

<p>When I activate the bounty, if you can answer this <a href="https://bchain.info/BTC/tx/96534da2f213367a6d589f18d7d6d1689748cd911f8c33a9aee754a80de166be" rel="noreferrer">refer to this Tx</a> as it can serve as the actual example (ie I'll provide ~$1 in BTC and private keys for 1From/1MBngSqZbMydscpzSoehjP8kznMaHAzh9y if interested)</p>

<p>EDIT 2: <a href="http://www.royalforkblog.com/2014/11/20/txn-demo/?#the-ins-and-outs-of-transactions" rel="noreferrer">The RoyalFork Blog: Deconstructing Txns</a> provides an unbelievably good reference for <strong>interactive</strong> Txn creation</p>

CC BY-SA 3.0
2014-11-20T04:56:13.600Z
You should read [Bitcoin the hard way.](http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html)
Nick ODell
CC BY-SA 3.0
2014-11-20T06:38:47.077Z
Are you looking for step by step with RPC calls, or step by step with byte manipulation by hand?
morsecoder
CC BY-SA 3.0
2014-11-21T03:28:42.587Z
@NickODell - yes, have seen that, Nick, and you're right, it's a *fantastic* resource! The issue still remains though even after reading the Python code... I just don't get the whole **ScriptPubKey** / **scriptSig** part and every resource I read is very opaque at that part. I'll edit the question to provide more clarity once I can put up the bounty
Wizard Of Ozzie
CC BY-SA 3.0
2014-11-21T03:33:48.953Z
@StephenM347 Aiming for a step by step example which is as close to *how would I create a Bitcoin transaction with pencil and paper?* (similar to:  http://bitcoin.stackexchange.com/q/808/9382 ). I am certainly avoiding RPC calls which "do the work" so to speak
Wizard Of Ozzie
CC BY-SA 3.0
2014-11-21T05:17:00.213Z
Do you care that it uses the exact txid you mentioned? I just think it would be easier to do it with a tx that I own. I wouldn't reveal the private key, but I would make the signatures that it calculates known.
morsecoder
CC BY-SA 3.0
2014-11-24T05:43:09.020Z
@stephenm347 it doesn't have to be that tx. If you'd like to reference your own txn that's fine too but I've setup this because the outputs are from 1From and the 1MB address is a brainwallet which happens to reference letters the same as 1MB (so private key is easy to link to the address)
Wizard Of Ozzie
CC BY-SA 3.0
2014-11-24T05:54:50.277Z
@StephenM347 For the bounty I need the private keys so I can repeat the process myself. Even Nick's suggestion to check out "Bitcoin the hard way" references the stack exchange How To Redeem A Raw TX so there is no canonical answer to this online; https://github.com/shirriff/bitcoin-code/blob/master/txnUtils.py
Wizard Of Ozzie
CC BY-SA 3.0
2014-11-24T06:20:20.317Z
Note that even if you repeat the process provided, the signature produced may not be identical to the one in the instructions.  That's because DSA/ECDSA signatures need to be produced with a secret value (often called `k`) and one method for producing a secret value is a one-time random number.  If you want perfectly reproducible steps, you should specify either that the value of `k` be provided in the instructions or that [RFC6979](http://tools.ietf.org/html/rfc6979) deterministic generation of `k` be used.
David A. Harding
<transactions><raw-transaction><raw-data>
Redeeming a raw transaction step by step example required
Wizard Of Ozzie
# Redeeming a raw transaction step by step example required

(Asked by: username_0 on 2014-11-20)

I am looking, specifically, for a step by step example transaction of sending Bitcoin which uses an *actual transaction* ([How To Redeem A Basic Txn](https://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx), from a few years back, does a great job of outlining most steps of sending a raw txn but [does not use a real TxID](http://blockexplorer.com/tx/f2b3eb2deb76566e7324307cd47c35eeb88413f971d88519859b1834307ecfec)).

I have played around with both the Python pybitcointools library, the [SX library](http://sx.dyne.org) and JSON output from the Bitcoin Core client (Bitcoin-QT, Bitcoin-cli, Bitcoin daemon) but have yet to find an actual step by step guide using raw transaction output (single input / single output Bitcoin txn, ie not multisig).

Hopefully the bounty will bring a step by step example transaction (with private keys for the sending address) will bring an answer showing how it's done and, specifically:

* how the ScriptPubKey element fits into the raw txn
* how the ScriptSig element fits into the raw txn
* how the txn is signed (with DER encoding).

EDIT: I think the best resource is [Ken Shirriff's *Bitcoins the hard way: Using the raw Bitcoin protocol*](http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html), but again, there's no single source online that answers my question without skimming past areas like scriptPubKey, signing etc.

When I activate the bounty, if you can answer this [refer to this Tx](https://bchain.info/BTC/tx/96534da2f213367a6d589f18d7d6d1689748cd911f8c33a9aee754a80de166be) as it can serve as the actual example (ie I'll provide ~$1 in BTC and private keys for 1From/1MBngSqZbMydscpzSoehjP8kznMaHAzh9y if interested)

EDIT 2: [The RoyalFork Blog: Deconstructing Txns](http://www.royalforkblog.com/2014/11/20/txn-demo/?#the-ins-and-outs-of-transactions) provides an unbelievably good reference for **interactive** Txn creation

**Tags:** transactions, raw-transaction, raw-data

> **Comments:**
> **username_1**: You should read [Bitcoin the hard way.](http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html)  
> **username_2**: Are you looking for step by step with RPC calls, or step by step with byte manipulation by hand?  
> **username_0**: @username_1 - yes, have seen that, username_1, and you're right, it's a *fantastic* resource! The issue still remains though even after reading the Python code... I just don't get the whole **ScriptPubKey** / **scriptSig** part and every resource I read is very opaque at that part. I'll edit the question to provide more clarity once I can put up the bounty  
> **username_0**: @StephenM347 Aiming for a step by step example which is as close to *how would I create a Bitcoin transaction with pencil and paper?* (similar to:  http://bitcoin.stackexchange.com/q/808/9382 ). I am certainly avoiding RPC calls which "do the work" so to speak  
> **username_2**: Do you care that it uses the exact txid you mentioned? I just think it would be easier to do it with a tx that I own. I wouldn't reveal the private key, but I would make the signatures that it calculates known.  
> **username_0**: @stephenm347 it doesn't have to be that tx. If you'd like to reference your own txn that's fine too but I've setup this because the outputs are from 1From and the 1MB address is a brainwallet which happens to reference letters the same as 1MB (so private key is easy to link to the address)  
> **username_0**: @StephenM347 For the bounty I need the private keys so I can repeat the process myself. Even username_1's suggestion to check out "Bitcoin the hard way" references the stack exchange How To Redeem A Raw TX so there is no canonical answer to this online; https://github.com/shirriff/bitcoin-code/blob/master/txnUtils.py  
> **username_3**: Note that even if you repeat the process provided, the signature produced may not be identical to the one in the instructions.  That's because DSA/ECDSA signatures need to be produced with a secret value (often called `k`) and one method for producing a secret value is a one-time random number.  If you want perfectly reproducible steps, you should specify either that the value of `k` be provided in the instructions or that [RFC6979](http://tools.ietf.org/html/rfc6979) deterministic generation of `k` be used.  

---

## 2 answers

### Answer by username_5 on 2014-11-24. Score: 53 | Accepted answer

**Step-by-step description:**

We start creating a new transaction which we hash and sign.

1. Add four-byte version field: `01000000`
2. One-byte varint specifying the number of inputs: `01`
3. 32-byte hash of the transaction from which we want to redeem an output (reverse order): `be66e10da854e7aea9338c1f91cd489768d1d6d7189f586d7a3613f2a24d5396`
4. Four-byte field denoting the output index we want to redeem from the transaction with the above hash (counting from zero): `00000000`
5. Now comes the scriptSig. For the purpose of signing the transaction, this is temporarily filled with the scriptPubKey of the output we want to redeem. First we write a one-byte varint which denotes the length of the scriptSig (0x19 = 25 bytes): `19`
6. Then we write the actual scriptSig (which is the scriptPubKey of the output we want to redeem): `76 a9 14 dd6cce9f255a8cc17bda8ba0373df8e861cb866e 88 ac` (look to the bottom line line on <https://blockchain.info/tx/96534da2f213367a6d589f18d7d6d1689748cd911f8c33a9aee754a80de166be?show_adv=true> )
7. Then we write a four-byte field denoting the sequence. This is currently always set to 0xffffffff: `ffffffff`
8. Next comes a one-byte varint containing the number of outputs in our new transaction. We will set this to 1 in this example: `01`
9. We then write an 8-byte field (64 bit integer, little-endian) containing the amount we want to redeem from the specified output. I will set this to the total amount available in the output minus a fee of 0.0001 BTC (128307 - 10000): `23ce010000000000`
10. Then we start writing our transaction's output. We start with a one-byte varint denoting the length of the output script (0x19 or 25 bytes): `19`
11. Then the actual output script: `76 a9 14 a2fd2e039a86dbcf0e1a664729e09e8007f89510 88 ac` ( this is transferring funds back to address 1FromKBPAS8MWsk1Yv1Yiu8rJbjfVioBHc )
12. Then we write the four-byte "lock time" field: `00000000`
13. And at last, we write a four-byte "hash code type" (1 in our case): `01000000`

OK, the result is

```
01000000
01
be66e10da854e7aea9338c1f91cd489768d1d6d7189f586d7a3613f2a24d5396
00000000
19 76 a9 14 dd6cce9f255a8cc17bda8ba0373df8e861cb866e 88 ac
ffffffff
01
23ce010000000000
19 76 a9 14 a2fd2e039a86dbcf0e1a664729e09e8007f89510 88 ac
00000000
01000000

```

14. Now we double-SHA256 hash this entire structure, which yields the hash `1cde0239b55717cca8003104abc2ec2673d4f6fabea0b74351940e382e88486f`
15. Now we should create ECDSA signature...
    `1MBngSqZbMydscpzSoehjP8kznMaHAzh9y` is a brainwallet of *"mrbubbymrbubbymrbubby!"*, which just happens to encode an address starting in *'MB'* (making linking the 2 quite easy; see @WizardOfAussie comment below for phrase origins).
    Private key in WIF: `5HvofFG7K1e2aeWESm5pbCzRHtCSiZNbfLYXBvxyA57DhKHV4U3`

In hex, the private key is `0ecd20654c2e2be708495853e8da35c664247040c00bd10b9b13e5e86e6a808d`. There is a sign (key, digest) method in every crypto lib. It will return an array of bytes. This array will be no more than 72 bytes, and start with hex code 30. Lets imagine that the signature is `3046022100cf4d7571dd47a4d47f5cb767d54d6702530a3555726b27b6ac56117f5e7808fe0221008cbb42233bb04d7f28a715cf7c938e238afde90207e9d103dd9018e12cb7180e`
To this signature we append the one-byte hash code type: `01`. The public key for 1MBngSqZbMydscpzSoehjP8kznMaHAzh9y is: `042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9`

16. We construct the final scriptSig by concatenating: <One-byte script OPCODE containing the length of the DER-encoded signature plus the one-byte hash code type>|< The actual DER-encoded signature plus the one-byte hash code type>|< One-byte script OPCODE containing the length of the public key>|<The actual public key>

scriptSig will be

```
49 3046022100cf4d7571dd47a4d47f5cb767d54d6702530a3555726b27b6ac56117f5e7808fe0221008cbb42233bb04d7f28a715cf7c938e238afde90207e9d103dd9018e12cb7180e 01
41 042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9

```

first line is 'push signature concatenated with 01', second line is 'push pubkey'. The length of scriptSig is 140 bytes (0x8c in hex)

17. We then replace the one-byte, varint length-field from step 5 with the length of the data from step 16. The length is 140 bytes, or 0x8C bytes: `8c`
18. And we replace the actual scriptSig with the data structure constructed in step 16.
19. We finish off by *removing* the four-byte hash code type we added in step 13, and we end up with the following stream of bytes, which is the final transaction:

    01000000
    01
    be66e10da854e7aea9338c1f91cd489768d1d6d7189f586d7a3613f2a24d5396
    00000000
    8c
    49 3046022100cf4d7571dd47a4d47f5cb767d54d6702530a3555726b27b6ac56117f5e7808fe0221008cbb42233bb04d7f28a715cf7c938e238afde90207e9d103dd9018e12cb7180e 01
    41 042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9
    ffffffff
    01
    23ce010000000000
    19 76 a9 14 a2fd2e039a86dbcf0e1a664729e09e8007f89510 88 ac
    00000000

> **Comments:**
> **username_6**: Isn't this the steps outlined in the link in the question? I don't this this qualifies for the bounty. @username_0 one thing you have to understand about bitcoin is that testing transactions is unlike any other computer program in history: it is impossible to replicate the same situation twice as is normally the case with testing. ie you can never go back a re-run the exact same situation again.  
> **username_5**: I do not pretend for bounty. I've just answered a question. And yes, most of my answer is pure copy-paste. May be very small additions. English is not my native language and it is hard for me to write the whole answer myself :)  
> **username_0**: I understand now! @username_5 if you want the private keys to edit your answer I can provide it (or I can edit the answer and give the privkey). Fyi it was the DER encoding (the part starting with a 0x30 byte) which I couldn't for the life of me place. I knew there was the 130 char public key starting with 0x04 within the byte array but I couldn't place the first part. I do understand it's going to be signed differently each time (one would hope!) but this is exactly the clarification I needed. I'll likely have to wait until I'm not using the iOS app to award the bounty but username_5 thank you!  
> **username_5**: You should not publish your private keys. You even should not send me your keys (my email is in profile). I think that my answer is full enough, nobody needs that the result been correct transaction existing in blockchain.  
> **username_0**: I appreciate what you're getting at (and the fabulous answer!) but the addresses are not holding BTC. The whole point of this was to have a canonical answer which is not testnet or regtest or abstract. So I'm going to edit your answer as I've successfully signed the txn and transmitted it. https://blockchain.info/tx/211b8fb30990632751a83d1dc4f0323ff7d2fd3cad88084de13c9be2ae1c6426  
> **username_0**: I'll add an answer outlining the process using sx tools but for those interested the brainwallet for 1MB... is "mrbubbymrbubbymrbubby!" (no quotes) => 1MBngSqZbMydscpzSoehjP8kznMaHAzh9y ... in case you're wondering it's what the neighbor yells each night to call her cat. It just so happens to hash to 1MB :)  
> **username_5**: Waiting for your next question: how to redeem two outputs in one tx (how to create & sign transaction with more than one input)  
> **username_0**: @username_5 Found this AWESOME reference; this blog is unbelievably good for visual ppl like myself... http://www.royalforkblog.com/2014/11/20/txn-demo/?#the-ins-and-outs-of-transactions  
> **username_7**: This is great! However, how is the raw transaction constructed when there are more than one input / output?  
> **username_8**: Is there a bip that describes the above?  
> **username_9**: It's great post. Thanks. I wrote some code based on your great answer but my code doesn't run. Could you help take a look at https://bitcoin.stackexchange.com/questions/92005/verify-bitcoin-transaction ? Thanks a lot.  

---

### Answer by username_4 on 2016-02-12. Score: 4

This is an excellent answer by username_5 and username_0 of username_0. I'd just like to add some more detail for the username_0 of username_0's transaction at [blockchain.info](https://blockchain.info/tx/211b8fb30990632751a83d1dc4f0323ff7d2fd3cad88084de13c9be2ae1c6426).

1. The correct input to the signature process for this transaction is

   ```
    01000000
    01
    be66e10da854e7aea9338c1f91cd489768d1d6d7189f586d7a3613f2a24d5396
    00000000
    19 76 a9 14 dd6cce9f255a8cc17bda8ba0373df8e861cb866e 88 ac
    ffffffff
    01
    23ce010000000000
    19 76 a9 14 2bc89c2702e0e618db7d59eb5ce2f0f147b40754 88 ac
    00000000
    01000000

   ```
2. The double-SHA256 hash of this is computed by `bx` as

   ```
    d304448dff517bcf677cd36f3491e9ef2ccfdf40fb63af5782d9b768640af130

   ```

but this is written in "reverse" order for whatever peculiar historical reason (I've heard it was to be compatible with M\*soft CRAPi). So when using this with the `sign(key, digest)` in most sensible crypto toolkits you may need to reverse the hash value to the "proper" order for `SHA256(SHA256(m))`

```
30f10a6468b7d98257af63fb40dfcf2cefe991346fd37c67cf7b51ff8d4404d3

```

3. The above input data will indeed validate against the signature given in the actual blockchain transaction

   ```
     3045022100da43201760bda697222002f56266bf65023fef2094519e13077f777baed553b102205ce35d05eabda58cd50a67977a65706347cc25ef43153e309ff210a134722e9e

   ```

using the given public key

```
042daa93315eebbe2cb9b5c3505df4c6fb6caca8b756786098567550d4820c09db988fe9997d049d687292f815ccd6e7fb5c1b1a91137999818d17c73d0f80aef9

```

4. To generate a reproducible signature over the same data, the following signature has been made by the deterministic method of [RFC6979](https://www.rfc-editor.org/rfc/rfc6979).

   ```
    30450220587ce0cf0252e2db3a7c3c91b355aa8f3385e128227cd8727c5f7777877ad772022100edc508b7c14891ed15ab38c687019d7ebaf5c12908cf21a83e8ae57e8c47e95c

   ```

using the matching private key provided by username_0 of username_0

```
0ecd20654c2e2be708495853e8da35c664247040c00bd10b9b13e5e86e6a808d

```

This signature also validates over the given data using the public key and should be reproducible.


---

