<blockquote>
<p>is it expected that the scriptSigs for unlocking those P2A always be empty?</p>
</blockquote>
<p>Yes.</p>
<blockquote>
<p>Would a transaction spending one of those with a non-empty scriptSig be considered non-standard?</p>
</blockquote>
<p>Not just non-standard; doing so would be consensus invalid.</p>
<p>A Pay-to-Anchor output is a native segwit output, as defined by BIP141. A segwit output is an output whose scriptPubKey consists of an <em>OP_n</em> (n between 0 and 16, inclusive) followed by a push between 2 and 40 bytes, inclusive. It happens to be one that has no version-specific consensus rules associated with it, but it is a segwit output no less.</p>
<p>Native segwit outputs are subject to a number of rules, but one of them is that they can only be spent using an empty scriptSig (as their spending information is expected to be found in the witness).</p>
<p>If you were to try to spend a P2A using an input with a non-empty <em>witness</em>, that would be legal and non-standard. But a non-empty scriptSig is outright invalid.</p>

CC BY-SA 4.0
2024-10-30T14:19:21.510Z
Thank you! I was not making the correct distinction between the scriptSig and the witness. Ended up learning more than I came for! Cheers.
thunderbiscuit
CC BY-SA 4.0
2024-10-29T20:09:36.507Z
2024-10-29T20:09:36.507Z
Pieter Wuille
<p>I understand the new P2A outputs have a scriptPubKey that looks like this: <code>OP_1 OP_PUSHBYTES_2 4e73</code>. If my understanding is correct this means that to unlock them you don't need a scriptSig at all, because the script interpreter will simply add both values on the stack and since the final result is neither 0 nor an empty array the script evaluates to true and succeeds.</p>
<p>My question is this: is it expected that the scriptSigs for unlocking those P2A always be empty? Would a transaction spending one of those with a non-empty scriptSig be considered non-standard?</p>

<segregated-witness><input-script><pay-to-anchor>
Is the scriptSig spending an PayToAnchor output expected to always be empty?
thunderbiscuit
# Is the scriptSig spending an PayToAnchor output expected to always be empty?

(Asked by: username_0 on 2024-10-29)

I understand the new P2A outputs have a scriptPubKey that looks like this: `OP_1 OP_PUSHBYTES_2 4e73`. If my understanding is correct this means that to unlock them you don't need a scriptSig at all, because the script interpreter will simply add both values on the stack and since the final result is neither 0 nor an empty array the script evaluates to true and succeeds.

My question is this: is it expected that the scriptSigs for unlocking those P2A always be empty? Would a transaction spending one of those with a non-empty scriptSig be considered non-standard?

**Tags:** segregated-witness, input-script, pay-to-anchor


---

## 1 answers

### Answer by username_1 on 2024-10-29. Score: 5 | Accepted answer

> is it expected that the scriptSigs for unlocking those P2A always be empty?

Yes.

> Would a transaction spending one of those with a non-empty scriptSig be considered non-standard?

Not just non-standard; doing so would be consensus invalid.

A Pay-to-Anchor output is a native segwit output, as defined by BIP141. A segwit output is an output whose scriptPubKey consists of an *OP\_n* (n between 0 and 16, inclusive) followed by a push between 2 and 40 bytes, inclusive. It happens to be one that has no version-specific consensus rules associated with it, but it is a segwit output no less.

Native segwit outputs are subject to a number of rules, but one of them is that they can only be spent using an empty scriptSig (as their spending information is expected to be found in the witness).

If you were to try to spend a P2A using an input with a non-empty *witness*, that would be legal and non-standard. But a non-empty scriptSig is outright invalid.

> **Comments:**
> **username_0**: Thank you! I was not making the correct distinction between the scriptSig and the witness. Ended up learning more than I came for! Cheers.  

---

