<p>Okay, turns out my research has led me to answer my own question, mainly from <a href="http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html" rel="nofollow noreferrer">here</a> though it did lack a bit of explanation or didn't explain, I think, as clearly as it could.  So here's my reading/interpretation/translation thereof.  (Go to that page to see the source of my data if need be).</p>

<p>NOTE:  This process may have changed after the addition of "segwit" either in its "lock-in" or its "activation".  I cannot speak to that.</p>

<p>A Quote from that page:</p>

<blockquote>
  <p>The final scriptSig contains the signature along with the public key for the source address (1MMMMSUb1piy2ufrSguNUdFmAcvqrQF8M5). This proves I am allowed to spend these bitcoins, making the transaction valid.</p>
</blockquote>

<p><strong>Step 1.</strong>  The signature in a given transaction will begin with <code>473044</code>
(these are standard from what I can see).</p>

<p><strong>Step 2.</strong>  Then you must append <code>0120</code> to the end of that number to get <code>4730440120</code></p>

<p>SIDE NOTE: <em>There are variations upon this which are demonstrated in old transactions and may still exist where you do NOT put that in and you put a different number instead.  I cannot account for and or explain those instances except to say that the "01" designates this as the first integer, and "20" designates the integer length of 32 bits (the "20" is in hex, just convert it to integer to get 32).  32 bits means there are 64 hex alphanumeric characters (0-9 and or a-f).</em></p>

<p><strong>Step 3.</strong> Then you must append the hex value of "r" from the ECDSA signature (which is 2cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff713), resulting in:
<code>47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff713</code></p>

<p><strong>Step 4.</strong> Then you append '0220' to the end of the previous code, resulting in
<code>47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff7130220</code></p>

<p>SIDE NOTE: <em>There are exceptions to adding merely "0220" that may exist or have existed in previous transactions throughout the block chain.  The only tool I can give to explaining them is the "02" is in reference to the "second integer" and the "20" designates the integer length of 32 bits (the "20" is in hex, just convert it to integer to get 32).  32 bits means there are 64 hex alphanumeric characters (0-9 and or a-f).  This is just as the "0120" is.  So if there is a third integer I think it would be preceeded by a "03" and if the integer is longer or shorter than 32 bits (or 64 hex alphanumeric characters) then the "20" should be changed to the hex value of half the number of the hex alphanumeric characters.  Just count them, divide by two, then convert decimal to hex to get the correct number to place here, if the need were to arise.</em></p>

<p><strong>Step 5.</strong> Then you must append the "s" value from the ECDSA signature (which I will not get into in this post) which is <code>6c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168223e82</code>
Resulting in:
<code>47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff71302206c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168223e82</code></p>

<p><strong>Step 6.</strong> Next you append a '01" which is "SIGHASH_ALL".  I don't know what that really means or fully stands for.</p>

<p><strong>Step 7.</strong> Append "41" which is "Pushdata41".  I don't know what the really means or fully stands for.</p>

<p><strong>Step 8.</strong> Append "04" to reference the type of public keys you are going to represent for the public key that this transaction is coming from.</p>

<p>NOTE:  "04" is in reference to a particular uncompressed "public key".  Bitcoin usually uses "02" at this point in time.</p>

<p><strong>STEP 9.</strong> Append the X value followed by the Y value of the public key, in this case the values are: 
<code>14e301b2328f17442c0b8310d787bf3d8a404cfbd0704f135b6ad4b2d3ee7513</code>
and
<code>10f981926e53a6e8c39bd7d3fefd576c543cce493cbac06388f2651d1aacbfcd</code></p>

<p>NOTE:  If you were using a compressed public key, you would only show the first one.</p>

<p><strong>Result:</strong>
<code>47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff71302206c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168223e8201410414e301b2328f17442c0b8310d787bf3d8a404cfbd0704f135b6ad4b2d3ee751310f981926e53a6e8c39bd7d3fefd576c543cce493cbac06388f2651d1aacbfcd</code></p>

<p>I did not go into the <code>S</code> or <code>R</code> creation as I felt that they should be done in a separate post to keep things organized.</p>

CC BY-SA 3.0
2017-08-14T22:09:31.040Z
2017-08-14T22:43:45.790Z
2017-08-14T22:43:45.790Z
Mine
<p>+1 for solving your own question. There is a very good "reference" here: </p>

<pre><code>http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
https://en.bitcoin.it/wiki/Protocol_specification#tx 
http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx
</code></pre>

<p>The 47 at the beginning is the length of the following string (in hex),  here is some explanation of this ASN.1 structure:</p>

<pre><code># ASN.1 STRUCTURE FOR PRIVATE KEY:
#   30  &lt;-- declares the start of an ASN.1 sequence
#   74  &lt;-- length of following sequence 
#   02  &lt;-- declares the start of an integer
#   01  &lt;-- length of integer in bytes (1 byte)
#   01  &lt;-- value of integer (1)
#   04  &lt;-- declares the start of an "octet string"
#   20  &lt;-- length of string to follow (32 bytes)
#           7d 86 0c 9a 9b 19 47 9b 19 1f 99 23 a7 12 ... df f9 43 43 58 f2 26 23 bc 
#           \----------------------------------------------------------------------/
#            this is the private key 
#   a0   &lt;-- declares the start of context-specific tag 0
#   07   &lt;-- length of context-specific tag 
#   06   &lt;-- declares the start of an object ID
#   05   &lt;-- length of object ID to follow 
#   2b 81 04 00 0a &lt;-- the object ID of the curve secp256k1
#   a1   &lt;-- declares the start of context-specific tag 1
#   44   &lt;-- declares the length of context-sepcifc tag (68 bytes)
#   03   &lt;-- declares the start of a bit string
#   42   &lt;-- length of bit string to follow (66 bytes)
#   00   &lt;-- ??
#            04 f1 44 f0 dc 00 80 af d2 b7 3f 13 37 6c ... 05 49 cd 83 f4 58 56 1e
#            \-------------------------------------------------------------------/
#             this is the public key
</code></pre>

CC BY-SA 3.0
2017-08-15T07:59:48.727Z
2017-08-15T07:59:48.727Z
pebwindkraft
<p>Could someone please explain how to do this is in a detailed step by step manner that correlates to a real linked transaction such that a n00b can comprehend?  Is it just copy and paste a particular identifiable portion of the previous tx from the raw tx thereof or is it more elaborate?</p>

<raw-transaction><input-script>
How do you create a scriptsig for a new raw tx?
Mine
# How do you create a scriptsig for a new raw tx?

(Asked by: username_0 on 2017-08-14)

Could someone please explain how to do this is in a detailed step by step manner that correlates to a real linked transaction such that a n00b can comprehend? Is it just copy and paste a particular identifiable portion of the previous tx from the raw tx thereof or is it more elaborate?

**Tags:** raw-transaction, input-script


---

## 2 answers

### Answer by username_0 on 2017-08-14. Score: 2 | Accepted answer

Okay, turns out my research has led me to answer my own question, mainly from [here](http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html) though it did lack a bit of explanation or didn't explain, I think, as clearly as it could. So here's my reading/interpretation/translation thereof. (Go to that page to see the source of my data if need be).

NOTE: This process may have changed after the addition of "segwit" either in its "lock-in" or its "activation". I cannot speak to that.

A Quote from that page:

> The final scriptSig contains the signature along with the public key for the source address (1MMMMSUb1piy2ufrSguNUdFmAcvqrQF8M5). This proves I am allowed to spend these bitcoins, making the transaction valid.

**Step 1.** The signature in a given transaction will begin with `473044`
(these are standard from what I can see).

**Step 2.** Then you must append `0120` to the end of that number to get `4730440120`

SIDE NOTE: *There are variations upon this which are demonstrated in old transactions and may still exist where you do NOT put that in and you put a different number instead. I cannot account for and or explain those instances except to say that the "01" designates this as the first integer, and "20" designates the integer length of 32 bits (the "20" is in hex, just convert it to integer to get 32). 32 bits means there are 64 hex alphanumeric characters (0-9 and or a-f).*

**Step 3.** Then you must append the hex value of "r" from the ECDSA signature (which is 2cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff713), resulting in:
`47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff713`

**Step 4.** Then you append '0220' to the end of the previous code, resulting in
`47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff7130220`

SIDE NOTE: *There are exceptions to adding merely "0220" that may exist or have existed in previous transactions throughout the block chain. The only tool I can give to explaining them is the "02" is in reference to the "second integer" and the "20" designates the integer length of 32 bits (the "20" is in hex, just convert it to integer to get 32). 32 bits means there are 64 hex alphanumeric characters (0-9 and or a-f). This is just as the "0120" is. So if there is a third integer I think it would be preceeded by a "03" and if the integer is longer or shorter than 32 bits (or 64 hex alphanumeric characters) then the "20" should be changed to the hex value of half the number of the hex alphanumeric characters. Just count them, divide by two, then convert decimal to hex to get the correct number to place here, if the need were to arise.*

**Step 5.** Then you must append the "s" value from the ECDSA signature (which I will not get into in this post) which is `6c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168223e82`
Resulting in:
`47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff71302206c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168223e82`

**Step 6.** Next you append a '01" which is "SIGHASH\_ALL". I don't know what that really means or fully stands for.

**Step 7.** Append "41" which is "Pushdata41". I don't know what the really means or fully stands for.

**Step 8.** Append "04" to reference the type of public keys you are going to represent for the public key that this transaction is coming from.

NOTE: "04" is in reference to a particular uncompressed "public key". Bitcoin usually uses "02" at this point in time.

**STEP 9.** Append the X value followed by the Y value of the public key, in this case the values are:
`14e301b2328f17442c0b8310d787bf3d8a404cfbd0704f135b6ad4b2d3ee7513`
and
`10f981926e53a6e8c39bd7d3fefd576c543cce493cbac06388f2651d1aacbfcd`

NOTE: If you were using a compressed public key, you would only show the first one.

**Result:**
`47304401202cb265bf10707bf49346c3515dd3d16fc454618c58ec0a0ff448a676c54ff71302206c6624d762a1fcef4618284ead8f08678ac05b13c84235f1654e6ad168223e8201410414e301b2328f17442c0b8310d787bf3d8a404cfbd0704f135b6ad4b2d3ee751310f981926e53a6e8c39bd7d3fefd576c543cce493cbac06388f2651d1aacbfcd`

I did not go into the `S` or `R` creation as I felt that they should be done in a separate post to keep things organized.


---

### Answer by username_1 on 2017-08-15. Score: 1

+1 for solving your own question. There is a very good "reference" here:

```
http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
https://en.bitcoin.it/wiki/Protocol_specification#tx 
http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx

```

The 47 at the beginning is the length of the following string (in hex), here is some explanation of this ASN.1 structure:

```
# ASN.1 STRUCTURE FOR PRIVATE KEY:
#   30  <-- declares the start of an ASN.1 sequence
#   74  <-- length of following sequence 
#   02  <-- declares the start of an integer
#   01  <-- length of integer in bytes (1 byte)
#   01  <-- value of integer (1)
#   04  <-- declares the start of an "octet string"
#   20  <-- length of string to follow (32 bytes)
#           7d 86 0c 9a 9b 19 47 9b 19 1f 99 23 a7 12 ... df f9 43 43 58 f2 26 23 bc 
#           \----------------------------------------------------------------------/
#            this is the private key 
#   a0   <-- declares the start of context-specific tag 0
#   07   <-- length of context-specific tag 
#   06   <-- declares the start of an object ID
#   05   <-- length of object ID to follow 
#   2b 81 04 00 0a <-- the object ID of the curve secp256k1
#   a1   <-- declares the start of context-specific tag 1
#   44   <-- declares the length of context-sepcifc tag (68 bytes)
#   03   <-- declares the start of a bit string
#   42   <-- length of bit string to follow (66 bytes)
#   00   <-- ??
#            04 f1 44 f0 dc 00 80 af d2 b7 3f 13 37 6c ... 05 49 cd 83 f4 58 56 1e
#            \-------------------------------------------------------------------/
#             this is the public key

```


---

