OP_RETURN outputs

I’m writing an article about Stacks consensus and the specification in the whitepaper is very high level, not going into any detail about messages exchanged between block producers and stackers.

I saw Bitcoin PoX transactions that in their first output have OP_RETURN ‘id’ and some others that start with OP_RETURN ‘X2’. What is the difference between them?

Can you clarify the types of Stacks transactions that I would see normally in the Bitcoin blockchain during the reward cycle ?



X2 is Stacks 2.0, whereas id is Stacks 1.0.

X2 has five extant operations:

  • VRF key registers (X2^)
  • Block commits (X2[),
  • Stack-STX (X2x),
  • Transfer-STX (X2$),
  • PreSTX (X2p)
  • User burn supports (not implemented, but documented in SIP-001)

The first to operations are concerned with mining. A miner registers a VRF public key once when it comes online, and uses the VRF private key to generate VRF seeds for blocks. The Stacks block must contain VRF proofs generated from this private key. Once its VRF key is registered, the miner proceeds to mine blocks by sending block-commit transactions (which encode the block hash, the parent/child linkage, the height, etc.).

Block-commit transactions can have either two PoX outputs, or a single burn output. The former is only accepted during a reward phase – the first 2000 Bitcoin blocks of a 2100-block reward cycle. The latter is only accepted during a prepare phase – the last 100 Bitcoin blocks of the reward cycle. The reason for this is that prepare-phase block-commits elect the reward set (the set of PoX payout addresses) for the next reward cycle by confirming a block-commit before the prepare phase, which makes it so determining which Stacks block (if any) encodes the reward set does not depend on the node having processed any prior Stacks blocks. This is important, because validating PoX block-commits in a reward phase depends on the node knowing which Stacks block to look at in order to determine the correct set of BTC addresses.

If no reward set was chosen in a prepare phase (i.e. no Stacks block received enough confirmations), then all block-commits in the subsequent reward cycle substitute two burn addresses in place of the two PoX outputs. Moreover, if a miner does not have the Stacks block whose block-commit was elected to chose the reward set, it will be unable to validate PoX block-commits that may arise in this reward cycle. To recover, it will instead (1) build blocks off of an ancestor of this block, and (2) substitute two burn addresses for the PoX outputs, and in doing so, mine a fork which does not depend on the missing block. If the block is truly missing, then subsequent reward cycles will confirm the absence of this block, and thereby prevent a “late-arriving” block from triggering a chain-wide reorg that would otherwise cause unprocessable PoX block-commits to become valid.

The remaining three operations are concerned with empowering users to transfer and Stack their STX in the presence of network censorship. The PreSTX transaction simply registers a UTXO that must be consumed by a subsequent Transfer-STX or Stack-STX. These two operations will cause a stx-transfer or a stack-stx to occur, respectively, in a Stacks block selected in the subsequent Bitcoin block. The Stacks block selected in this subsequent Bitcoin block must include state-transitions for these operations as if they were Stacks transactions; otherwise the block will be invalid. This ensures that STX holders have a way of “routing around” uncooperative ISPs and STX miners – the Bitcoin transactions cannot be ignored for free.

That’s a lot of information! Thanks! But I must tell you that lacking some formal definitions it is hard for me to understand it in full.

First I will narrow the original question: Can a Stacks 1.0 “id” burn transaction appear in a Bitcoin block after the Stacks 2.0 was launched ? And in that case, what do they represent ? Is this tx interpreted or just discarded ?

Now, a new question (that may reveal my limited understanding of the protocol): each time a new Stacks block is created it is paired with a block-commit transaction in Bitcoin right? Also in this PoX transaction, it pays to several STX stackers. But I thought Stacks block producers first payed to stackers for the right to mine, and then they were selected by in a VRF to be leaders and create blocks, given each miner a certain number of predefined slots. Why do they pay again when creating blocks if they have already paid for the right to mine ?

You may want to take a look at SIP-001 and SIP-007 which describe the protocol in detail. Happy to clarify any terminology questions you have.

They are ignored. Stacks 2.0 only looks at Bitcoin transactions whose OP_RETURN outputs begin with X2.


Yes – it pays 2 stackers, but under the conditions described in SIP-007. Namely, PoX has to be “active” (which, so far, it has been).

That is correct. If you and I are both Stacks block miners, then after generating our blocks, we both send block-commit transactions on Bitcoin. We both pay to the same stackers. So, stackers receive both our BTC. The Stacks 2.0 software executes a cryptographic sortition algorithm (powered by the VRF) to choose one of us as the “winner.” The winner then replicates their block to the peer network. The loser does nothing.

This is not too different from how PoW works – competing miners all spend electricity to try and win the block race, but only one of them will produce a block that ends up on the canonical chain fork (with overwhelming probability). PoX replaces the electricity spend with a Bitcoin spend.

If you read SIP-001, the original system design was to simply have Stacks miners burn the Bitcoin, much like how the electricity in Bitcoin mining is burnt. SIP-007 refines this concept into instead sending the Bitcoin to people who have locked up their STX, on a randomized schedule that cannot be predicted in advance.

Per the above, they only pay once per block-commit. Each block-commit is an attempt to produce a block. At most one block-commit in a Bitcoin block will be selected as the “winning” block commit, so at most once Stacks block is appended to the Stacks chain per Bitcoin block mined.

Much better now!
I got confused because the whitepaper talks about a “round” without defining what a round is, and I thought a “round” was a cycle. But a “round” is just the process to select the leader for a single block, while a cycle is 2100 blocks.

Maybe you can improve the white paper and define what a round is.
I will keep researching.

1 Like

Regarding Stacks 1.0 “id” transactions, here is one of them, as recent as March 2021:

It probably means that this Stacks miner kept running the old Stacks 1.0 mining node by mistake. right?

Yup, looks like someone was using the Stacks 1.0 software there. That would have been a STX transfer back in the old days. Stacks 2.0 nodes ignore it.

1 Like