1

The scriptpubkey alone can be used to identify the type of address. However, I'm debugging a library that's having difficulty differentiating the following transaction/scriptpubkey from a p2tr transaction/scriptpubkey.

Erroneously marked p2tr:

Txid: 2b3733a39b87cef1f7c2ca8988583ec0c1a886651b040e3dbaf4c26be81d0f75:195

Scriptpubkey: 245a227ef640f3b1dc1815e6e39b482677f0f57b69de7775faec778c0950a8851805000000

Correctly marked p2tr:

Txid: 83c8e0289fecf93b5a284705396f5a652d9886cbd26236b0d647655ad8a37d82:0

Scriptpubkey: 5120a457d0c0399b499ed2df571d612ba549ae7f199387edceac175999210f6aa39d

And honestly.. I understand why the library is having issues. The problematic scriptpubkey does look like a p2tr (1, data). However one thing I noticed is the problematic tx doesn't have witness (predates segwit). Is the only solution to check witness stack for the right pattern?

Improve this question
1
  • A witness stack is part of an input’s data. If you are trying to identify an output, how does the witness stack come into play? Are you trying to figure out whether an input is spending a P2TR output?
    – Murch ♦
    Commented Mar 3 at 19:14

1 Answer 1

Reset to default
4

I don't see why that scriptPubKey would be incorrectly marked as P2TR as it absolutely does not follow the expected pattern. BIP 341 is very unambiguous as to the script construction - it must be OP_1 followed by a push of exactly 32 bytes.

The erroneously marked P2TR script is only a push of 36 bytes. It does not begin with OP_1, and the length of the data push is incorrect.

Is the only solution to check witness stack for the right pattern?

No. A transaction can consist of entirely non-segwit inputs and still create P2TR outputs. Such a transaction would not have any witness data.

Improve this answer

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.