Unlike previous versions, where multiple anchor outputs could be used in anchor-using transactions, version 3 enforces a policy where these outputs must be spent within the same transaction package. This approach aims to reduce UTXO (Unspent Transaction Output) set growth.

The implications of this change are significant when considering potential attacks on the system. In earlier models, if Alice were to broadcast a transaction with an anchor output, she would be spending her anchor, which would prevent Bob from attempting a double-spend attack. However, with the v3 update, this defensive mechanism is not possible. The new rule necessitates that anchors be used up as part of the same transaction package, therefore altering the dynamics between transacting parties.

Furthermore, the structure of anchor outputs will also differ in v3. These anchors will essentially be OP_1 outputs without any associated signature, meaning they are not distinctly owned by either party—Alice or Bob. This represents a departure from previous versions where the anchor output would be tied to a specific participant in the transaction.

For more detailed technical insights and discussions on this topic, interested readers can explore resources provided by Peter Todd, whose expertise in this domain is well-regarded. He can be contacted for further information at his email address, derived from his website: peter@petertodd.org.