1

There are three parts to this.

Shown here.

Part 1. This string is found at the final form of the raw tx:

494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01 eeffffff

But there is no explanation on how to get it or what it is nor does it appear to be from any other part of the tx. What is it and how do I get it from the data provided? Or is it merely the signature for the 1st input?

Part 2. This string is the preimage for the "sighash":

0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000

Why is it lacking the 1st input but has the hash that was derived from both the first and second inputs? How does one handle that part if your transaction only has 1 input? Or is this just the preimage for the second input?

Part 3. The above preimage for the sighash produces a signature. This signature of

02 47304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 21025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357

Why does this go at the bottom of the transaction in the "witness" preceded by a "02" and doesn't correlate with the input that it was created from (if it is indeed considered to be the signature for the 2nd output). If that is proper, then what does one do to create this "witness" thing at the end if one only has one input? And what does the "02" mean or what is it in reference to?

I was thinking of breaking this up into multiple questions but I think that would have gotten messy, not to mention I think these correlate with one another.

0

And what does the "02" mean or what is it in reference to?

This is the number of following chunks. Signature and public key

-1

part one: this is the script sig as part of the txin (it's fourth element on the page), and the tx sig script and the Sequence number behind is described here: https://bitcoin.org/en/developer-reference#raw-transaction-format, and decodes to:

  ##################################################################
  ### tcls_in_sig_script.sh: decode SIG_script OPCODES from a TX ###
  ##################################################################
    48: OP_DATA_0x48:     push hex 48 (decimal 72) bytes as data
    30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
    45: OP_LENGTH_0x45:   length of R + S
    02: OP_INT_0x02:      type tag indicating INTEGER
    21: OP_LENGTH_0x21:   this is SIG R
        008B9D1DC26BA6A9:CB62127B02742FA9
        D754CD3BEBF337F7:A55D114C8E5CDD30
        BE
    02: OP_INT_0x02:      type tag indicating INTEGER
    20: OP_LENGTH_0x20:   this is SIG S
        40529B194BA3F928:1A99F2B1C0A19C04
        89BC22EDE944CCF4:ECBAB4CC618EF3ED
    01: OP_SIGHASHALL:    this terminates the ECDSA signature (ASN1-DER structure)
    #########################################################
    ### procedure to strictly check DER-encoded signature ###
    #########################################################
    Minimum and maximum size constraints                        - ok
    scriptsig always starts with 0x30                           - ok
    length 138 chars is less than actual sig length (144 chars) - ok
           (hex 0x45, decimal 69, 138 chars)
    length of R coordinate (66) >= 0                            - ok
    length of S coordinate (64) >= 0                            - ok
    S-Value is within scriptsig boundaries                      - ok
    Make sure the R & S length covers the entire signature      - ok
    S-value must be smaller than N/2                            - ok
    strictly check DER-encoded signature                        - ok
    #########################################################

part two&three: I don't know to answer, searching as well for good explanation :-)


A bit late, but here we go: part two and three. As this all belongs to a segwit tx, it decodes slightly different than a normal tx. At the beginning would be a segwit marker and flag, and at the end the segwit data. You can see in TX_IN1, that the scriptsig length is 0. This part is then the witness data at the end of the tx:

VERSION
 01000000

SEGWIT (BIP141): this is a segwit tx, marker=00
       (BIP141): flag=01

TX_IN COUNT [var_int]: hex=02, decimal=2
 TX_IN[0]
  TX_IN[0] OutPoint hash (char[32])
  9F96ADE4B41D5433F4EDA31E1738EC2B36F6E7D1420D94A6AF99801A88F7F7FF
  TX_IN[0] OutPoint index (uint32_t)
  hex=00000000, reversed=00000000, decimal=0
  TX_IN[0] Script Length (var_int)
  hex=49, decimal=73
  TX_IN[0] Script Sig (uchar[])
  4830450221008B9D1DC26BA6A9CB62127B02742FA9D754CD3BEBF337F7A55D114C8E5CDD30BE022040529B194BA3F9281A99F2B1C0A19C0489BC22EDE944CCF4ECBAB4CC618EF3ED01 
  TX_IN[0] Sequence (uint32_t)
  EEFFFFFF
 TX_IN[1]
  TX_IN[1] OutPoint hash (char[32])
  8AC60EB9575DB5B2D987E29F301B5B819EA83A5C6579D282D189CC04B8E151EF
  TX_IN[1] OutPoint index (uint32_t)
  hex=01000000, reversed=00000001, decimal=1
  TX_IN[1] Script Length (var_int)
  hex=00, decimal=0
  TX_IN[1] Sequence (uint32_t)
  FFFFFFFF

TX_OUT COUNT, hex=02, decimal=2
 TX_OUT[0]
  TX_OUT[0] Value (uint64_t)
  hex=202CB20600000000, reversed_hex=0000000006B22C20, dec=112340000, bitcoin=1.12340000
  TX_OUT[0] PK_Script Length (var_int)
  hex=19, dec=25
  TX_OUT[0] pk_script (uchar[])
  76A9148280B37DF378DB99F66F85C95A783A76AC7A6D5988AC
 TX_OUT[1]
  TX_OUT[1] Value (uint64_t)
  hex=9093510D00000000, reversed_hex=000000000D519390, dec=223450000, bitcoin=2.23450000
  TX_OUT[1] PK_Script Length (var_int)
  hex=19, dec=25
  TX_OUT[1] pk_script (uchar[])
  76A9143BDE42DBEE7E4DBE6A21B2D50CE2F0167FAA815988AC

WITNESS TXIN[0] stack elements: hex=00, decimal=0
WITNESS TXIN[1] stack elements: hex=02, decimal=2
 WITNESS data[0]:
  47304402203609E17B84F6A7D30C80BFA610B5B4542F32A8A0D5447A12FB1366D7F01CC44A0220573A954C4518331561406F90300E8F3358F51928D43C212A8CAED02DE67EEBEE01
 WITNESS data[1]:
  21025476C2E83188368DA1FF3E292E7ACAFCDB3566BB0AD253F62FC70F07AEEE6357

 LOCK_TIME
11000000

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.