Pay to Anchor
The Pay to Anchor (P2A) output script isn’t a “locking script” in that sense. It requires no further enter to turn out to be legitimate for inclusion within the blockchain. It’s “ANYONE_CAN_SPEND”, i.e., anybody can create an enter that references the transaction output per its outpoint and spend it with an empty enter script and witness stack. After all each output continues to be distinctive (recognized per its outpoint) can solely be spent by one transaction.
Native Segwit Outputs
P2A falls within the class of native segwit output scripts. Native segwit output scripts observe the sample <Model>[push_<witness_program_length>]<witness_programm>. Because the segwit smooth fork was activated, all native segwit output scripts are thought-about legitimate except extra particular guidelines encumber them. Bitcoin Core 0.19.0 (in 2019) and newer additionally usually settle for transactions with future native segwit outputs. This makes it simple to smooth fork in new guidelines for future native segwit output sorts: unupgraded nodes (0.19.0+) think about them legitimate and customary, even earlier than they know the principles on learn how to interpret the output script. In the meantime, nodes that implement a smooth fork implement the brand new further guidelines on the corresponding outputs.
When Pay to Witness Public Key Hash (P2WPKH) and Pay to Witness Script Hash (P2WSH) had been launched, they had been designated “native segwit model 0” which is why their output scripts begin with OP_0 (which produces addresses that begin with bc1q). For native segwit v0, witness applications of 20-byte size should adhere to P2WPKH guidelines, witness applications of 32-byte size should adhere to P2WSH guidelines, and all different lengths beside 20 and 32 bytes had been declared invalid.
A distinct strategy was chosen for native segwit model 1. When Pay to Taproot (P2TR) was launched, it was designated that P2TR guidelines solely apply to native segwit outputs of 32-byte witness applications, and all different lengths had been left unencumbered. Native segwit v1 output scripts begin with OP_1 which produces addresses that begin with bc1p.
P2A can also be a Native Segwit v1 output script. It subsequently additionally begins with OP_1 and its deal with prefix is bc1p. The witness program was chosen to be the minimal permitted witness program size of two bytes. The 2 bytes had been chosen as a result of they trigger the ensuing deal with to include the string “charges”. P2A is all the time legitimate, just because all native segwit output scripts are thought-about legitimate and no additional guidelines had been launched to limit it. Anybody can spend any P2A output just by referencing the output’s outpoint (txid:vout) in a transaction enter with none additional data being vital within the enter. As with all inputs spending native segwit outputs, the enter script (aka scriptSig) is empty, however for P2A the witness stack can also be empty.
P2A’s associates: TRUC and 1P1C
P2A was launched in Bitcoin Core v28.0 along with two associated updates to mempool conduct: _ Topologically restricted till affirmation (TRUC) transactions_ and Opportunistic 1P1C Bundle Relay (1P1C). Briefly summarized, a sender can optionally create TRUC transactions which can be restricted to having both one youngster or one mum or dad and restricted in weight by setting the transaction model to three. This restricts TRUC transactions to packages of at most two associated transactions within the mempool (however a single TRUC transaction can also be allowed).
A node will usually learn about all UTXOs being spent by transactions, however typically, we’ll study a baby transaction earlier than seeing its mum or dad. In that case, we don’t learn about one of many UTXOs spent by the kid transaction, and we put this orphan transaction in an information construction we name the “orphanage”. 1P1C improves the orphan decision for packages with two transactions. Notably, we can not validate a transaction with unknown inputs, nor decide its feerate. After receiving one, we then ask the peer that introduced the kid to us for the mum or dad transaction.
Usually, when a node learns a couple of transaction that doesn’t meet its dynamic minimal feerate, it rejects that transaction. In prior variations, when the peer supplied the lacking mum or dad transaction, and the mum or dad transaction’s feerate didn’t meet our node’s minimal feerate, we’d reject the mum or dad and the orphan would linger within the orphanage. 1P1C improves the state of affairs such that when a mum or dad transaction is rejected because of not assembly the minimal feerate, whereas we have now its youngster within the orphanage, we subsequently attempt to submit mum or dad and youngster collectively as a bundle. If the kid’s price causes the bundle to fulfill or exceed the minimal feerate, each are added to the mempool directly. This additionally permits such transaction pairs with a low feerate mum or dad to propagate (though not reliably), which addresses a ache level of the lightning community the place feerates of dedication transactions needed to estimated excessive sufficient to make it into the mempool even when feerates spiked, as a result of CPFP was inadequate to get low feerate mum or dad transactions admitted to the mempool.
Ephemeral Mud
Bitcoin Core usually require that transaction outputs meet the mud restrict. Bitcoin Core v29.0 introduces a brand new mempool coverage referred to as Ephemeral Mud: a transaction might have a single output with an quantity decrease than the mud restrict if the transaction pays zero charges (which requires it to be a TRUC transaction). Any transaction spending unconfirmed outputs from the 0-fee mum or dad should spend the mud output. Because the 0-fee mum or dad transaction doesn’t meet the minimal feerate by itself that usually implies that it’s submitted with a baby transaction that instantly spends the mud output, making it ephemeral.
Ephemeral Anchors
Whereas P2A can be utilized independently from TRUC or Ephemeral Mud, TRUC can be utilized independently of P2A, and the brand new bundle submission rule can profit any 2-transaction bundle (see @glozow’s reply), Ephemeral Anchors use all collectively: (mum or dad) TRUC transactions might have a price of zero, P2A minimizes the transaction weight for creating CPFP packages, 1P1C permits for 2 associated transactions to be propagated as packages, and ephemeral mud ensures that anchor outputs don’t linger within the UTXO set. E.g., we will now have LN dedication transactions with zero charges and a P2A with an quantity of 0; if both celebration desires to unilaterally shut the channel, they connect a baby that pays the suitable charges estimated on the time of making the kid and the bundle propagates collectively. Moreover, 1P1C acquired an enchancment in Bitcoin Core v29.0: as a substitute of asking solely the peer that despatched us an orphan for the mum or dad transaction, the node will ask any peer that introduced the orphan which improves the robustness of 1P1C propagation.
The P2A Output Script in Element
As a result of the witness program is a mere two bytes, the P2A output script is just 4 bytes: 0x51024e73, OP_1, OP_PUSHBYTES_2, and the 2 byte witness program. This makes the complete output 13 bytes (8 bytes for the output quantity, one byte for the size of the output script, 4 bytes output script). And the complete enter 41 bytes (36 bytes for the outpoint that identifies which UTXO is being spent (32 bytes for the txid, 4 bytes for the vout), 4 bytes for the nSequence, and
Let’s search for instance at transaction 5bad…32dc. It has one P2TR keypath enter, one P2A output, and one P2TR output:
If you happen to check out the serialized transaction (by way of yogh.io), you see this:
(1) The 02 byte signifies two outputs, the subsequent (2) eight bytes 6d 03 00 00 00 00 00 00 encode an quantity of 877 satoshis, the (3) 04 signifies the size of the four-byte output script, and (4) we spot the mentioned P2A output script 0x51024e73.
The transaction that spends the P2A output 58a8bf720444561ca4cb9ae76d117854fbed5671dbbad0de4c81397e9fee05ae on the opposite facet, incorporates an enter that solely identifies which output it’s spending with an empty enter script and witness script:
Sadly, it appears to be like like yogh.io can not deal with transactions with P2A inputs but. Anyway, the transaction’s hex is:
0200000001dc3244a5e18ef8b38987a375956282839f96e36f04b75f068dcf63a837c1ad5b0000000000fdffffff010000000000000000116a0f696e20666565732077652072757374ac800d00
02000000 ↦ tx model 2
01 ↦ one enter
dc3244a5…37c1ad5b ↦ spent output’s txid (little endian) 5badc137…a54432dc
00000000 ↦ output’s place 0 in prior tx
00 ↦ enter script size of 0
fdffffff ↦ nSequence MAX-2
01 ↦ one output
0000000000000000 ↦ quantity of 0
11 ↦ 17 bytes of output script to observe
6a ↦ OP_RETURN
0f ↦ OP_PUSHBYTES_15
696e20666565732077652072757374 ↦ ASCII for "in charges we rust"
ac800d00 ↦ locktime of 884908
As you possibly can see, the enter has no witness stack, and the enter script size is zero, so the enter has the minimal weight of 41 bytes. Which means a P2A output plus enter merely manner 64 vB, which is way much less even than the prior champion amongst spendable customary transaction outputs, P2WPKH, which is available in at 99 vB (output of 31 vB + enter of 68 vB).
As a result of P2A has so little weight, it makes for an inexpensive manner of permitting any celebration to bump a transaction per a baby transaction.
Corrections
- A previous model of this reply acknowledged that P2A outputs had been non-standard earlier than the formal introduction of the P2A output script. All native segwit outputs are accepted as legitimate by any model of Bitcoin Core. Transactions spending to future native segwit variations are thought-about customary since Bitcoin Core 0.19.0. Thanks @gelenor.
- A previous model of this reply attributed the earlier non-standardness of Ephemeral Anchors to P2A outputs usually. Ephemeral Anchors had been non-standard because of violating the mud restrict, however P2A outputs with bigger quantities had been already usually accepted. Thanks @thunderbiscuit.
- A previous model of this reply didn’t correctly distinguish Ephemeral Mud and Ephemeral Anchors. Ephemeral Mud usually permits a single mud output on a 0-fee transaction, whereas Ephemeral Anchors refers back to the mixture of P2A and Ephemeral Mud in TRUC transactions collectively. Thanks @glozow.
