From 6a311752dd4744e3886ab110ab356627884022e2 Mon Sep 17 00:00:00 2001
From: "Johan T. Halseth" <johanth@gmail.com>
Date: Mon, 2 Jun 2025 14:09:04 -0600
Subject: [PATCH] BIP443: list stack elements in bottom-to-top order

and a few minor fixups
---
 bip-0443.mediawiki | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bip-0443.mediawiki b/bip-0443.mediawiki
index 620336e9..97f42fe1 100644
--- a/bip-0443.mediawiki
+++ b/bip-0443.mediawiki
@@ -38,7 +38,7 @@ This document is licensed under the 3-clause BSD license.
 The ability to constrain the future of coins beyond what is possible with presigned transactions is at the core of
 numerous attempts to improve bitcoin. Some of the proposed applications include:
 
-* UTXO sharing schemes like Ark, CoinPools, Timeout Trees, etc. use various types of output restrictions in order to enable multiple parties to share the control of a UTXO, while ensuring that each participant controls their own `balance.
+* UTXO sharing schemes like Ark, CoinPools, Timeout Trees, etc. use various types of output restrictions in order to enable multiple parties to share the control of a UTXO, while ensuring that each participant controls their own balance.
 * <code>OP_VAULT</code><ref>[[bip-0345.mediawiki|BIP-345]]</ref> is a proposed opcode to implement a 2-step withdrawal process, enabling on-chain reactive security.
 * <code>OP_CHECKTEMPLATEVERIFY</code><ref>[[bip-119.mediawiki|BIP-114]]</ref> is a long-proposed opcode to constrain a transaction to a ''template'' with a fixed set of outputs.
 * Sidechains and rollups could be implemented via a UTXO encumbered with a recursive covenant, updating the sidechain state root every time it is spent.
@@ -135,10 +135,10 @@ The tapscript opcode <code>OP_SUCCESS187</code> (<code>0xbb</code>) is constrain
 <code>OP_CHECKCONTRACTVERIFY</code>.
 
 When evaluating <code>OP_CHECKCONTRACTVERIFY</code> (<code>OP_SUCCESS187</code>,
-<code>0xbb</code>), the expected format of the stack, shown bottom to top, is:
+<code>0xbb</code>), the expected format of the stack, shown bottom-to-top, is:
 
 <source>
-<mode> <taptree> <pk> <index> <data>
+<data> <index> <pk> <taptree> <mode>
 </source>
 
 where:
@@ -462,4 +462,4 @@ without upgrade except for mining and block validation.
 
 == Acknowledgements ==
 
-TODO
\ No newline at end of file
+TODO