I am trying to obtain information about a raw transaction in hex before it is broadcasted. This command multiple elements JSON formatted. I'd like a simpler explanation for them:

txid - hash of the transaction itself

hash - hash of the transaction itself. If transaction is non-segwit, txid == hash, otherwise in segwit transactions the transaction hash is different.

version - this is obvious what it is, but how should be interpreted?

size - size of the transaction in bytes

vsize - weighted size for segwit transactions

locktime - lock time of this transaction either in block height either in unix time. OP_CLTV is only determinable from the redeemscript, not from this field.

vin - this subset includes all the inputs being spent.

  • txid - txid of the input being spent.
  • vout - what is this?
  • scriptSig - asm / hex - this includes the signature(s) and redeemScript of this particular input. Is there any difference between asm and hex?
  • sequence - how can this be interpreted? How can one determine if the input is either CSV locked, either replace-able by fee (RBF)?

vout - this subset includes all the outputs of the transaction:

  • value - amount of this output.
  • n - this looks like the number / ordering of outputs?
  • scriptPubKey - script or pubkeyhash of the output
  • reqSigs - how can this be known in advance by the sender, only by having the address?
  • type - how can this be know in advance as well?

Additional questions:

  • How can the amount of each input within the vin subset be determined?
  • How can the scriptSig be validated, like: is the input CLTV or CSV locked? Does the redeemScript (if p2sh) validate to true (e.g. required number of sigs available, other IF/ELSE rules fulfilled)?

Your post is a bit long, in stack exchange we prefer shotrt, easy to answer questions - see here: https://bitcoin.stackexchange.com/help/how-to-ask

You probably have an example of a JSON interpretation as reference. From where do you have it? As everyone can interpret a raw transaction, I think it is best to reference the original raw transaction from bitcoin.org. This is anambigous. It would look like this (non-segwit, to keep it easy going. Segwit only on demand :-)

TX_IN COUNT         (how many input this tx has)
  OutPoint hash     (the previous tx where funds come from)
  OutPoint index    (the n'th TX_IN)
  Script Length     (the length of the following Script Sig)
  Script Sig        (signature)
  Sequence          (a sequence field, originally intended to disable lock-time) 
TX_OUT COUNT        (how many outputs this tx has)
  Value             (the value in Satoshis)
  PK_Script Length  (length of the following script)
  pk_script         (the script, which defines the condition, under which the funds can be spent)
LOCKTIME            (earliest time or earliest block when that transaction may be added to the block chain)

The assembly of a tx before to be sent was pretty well explained by the answer of @amaclin here.

How can the amount of each input within the vin subset be determined?

The wallet software would need to lookup the values when wanting to spend a new tx. Therefor a reference to a previous tx is required, where v_in is found. If unsufficient for the current spent, then another v_in or even another tx with its v_in will be used (TX_IN count would be increased).

How can the scriptSig be validated, like: is the input CLTV or CSV locked?

I do not understand what you mean by this. Scriptsig and CLTV/CSV are not directly linked to scriptsig. CLTV and CSV both came into the game by BIP-68 and BIP-112. CLTV (as also locktime) are both absolute timelocks, with CSV we talk about relative timelocks. So they define, when a transaction's output can be spent. Maybe worthwhile to lookup in the BIPs. There is also lots in the forum here and in bitcointalk.

Scriptsig (in general) is validated with the hash and the pubkey. Ken Shirrif's blog (link at the bottom) explains very well. Scriptsig proofs, that you had the private key ("you are the rightful owner") to spend this transaction. The privkey signs a hash of the tx, which is followed by the pubkey. There can be more to it, but I want to stay general. Here is an example how you can verify a signature at the unixoide systems shell with openssl (bitcoin always uses hex encoded data to do hashes, and openssl needs a PEM formatted key):

printf $( echo $hash | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_utx_dsha256.hex
echo "MDYwEAYHKoZIzj0CAQYFK4EEAAoDIgAD9dD7lV+V3WvmEVzoVmHbQS7GoIq8v859oLqCl8bMDsQ=" > cat pubkey.pem
printf $( echo $sig | sed 's/[[:xdigit:]]\{2\}/\\x&/g' ) > tmp_sig.hex
openssl pkeyutl <tmp_utx_dsha256.hex -verify -pubin -inkey pubkey.pem -sigfile tmp_sig.hex

Does the redeemScript (if p2sh) validate to true (e.g. required number of sigs available, other IF/ELSE rules fulfilled)?

The redeemscript is basically a hash of "something". It has the advantage to "hide", what is intended, when the funding transaction is mined into the blockchain. When you create your spending transaction, then the data of your p2sh script is revealed. The common usage is a multisig script. But you can put all type of code into it, which would define the condition, under which funds can be spent (next to multisig, any type of smart contracts, ...). There are limitations to it. The OPCODES, that can be used are explained here. In bitcoin.org are also explanations on p2sh.

I learned all this from 2 additional references: the unbelievably well written book "Mastering Bitcoin" from Andreas, and a very good explanation on transactions by Ken Shirrif.

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.