0
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?
2
Okay, turns out my research has led me to answer my own question, mainly from here 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.
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
