-1

I'm trying to "distill" Taproot transactions in the raw transaction output, but:

  1. It is still not clear to me what tx version number a Taproot transaction uses.
  2. How to find out if it's a taproot transaction containing an inscription (in the witness) or just a normal tx with taproot signaled.
  3. Is there a way to know via the inputs (via getrawtransaction RPC call) if it's a TPR transaction?

1 Answer 1

4
  1. It is still not clear to me what tx version number a Taproot transaction uses.

Any transaction version number can have Taproot inputs or outputs.

  1. Is there a way to know via the ins (via getrawtransaction RPC call) if it's a TPR transaction?

There is no such thing as a "Taproot transaction"; there are Taproot outputs and Taproot inputs. Transactions can freely mix Taproot inputs with other inputs, and Taproot outputs with other outputs.

Taproot outputs can be recognized by having a scriptPubKey consisting of OP_1 followed by a 32-byte push.

Taproot inputs are defined as just inputs that spend taproot outputs. It is for now possible to recognize them just based on input data, though this is not guaranteed to remain possible with future upgrades:

  • If an input has exactly one witness stack item (after removing the optional annex, if any), it is either a Taproot key path spend, or a strange zero-input P2WSH spend.
  • If an input has two or more witness stack items (after removing the optional annex, if any), and the last item of those starts with byte 0xc0 or 0xc1, it is a BIP342 taproot script path spend (such an input cannot possibly be a P2WPKH spend as the prefix bytes are not valid public key header bytes, and not P2WSH spends, because those prefix bytes are invalid in script).
2
  • 2
    A P2WSH input whose witness script is satisfied by an empty initial stack will also have exactly one witness stack item. These are obviously rare, but it still means the heuristic is not perfect. Same goes for inputs spending unknown witness versions which can have any number of witness stack items (and are non-standard). You can somewhat improve the heuristic by only considering inputs whose single witness stack item has 64 or 65 bytes (in case of 65 bytes check that the last byte is an allowed sighash flag). Commented Sep 25, 2023 at 17:06
  • @VojtěchStrnad Oh yes, you're right. Commented Sep 25, 2023 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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