Move examples under motivation section

1 files changed, 42 insertions, 43 deletions

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index ae569b6..4773b17 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -50,6 +50,48 @@ minimum time after proof-of-publication. This enables a wide variety
 of applications in phased protocols such as escrow, payment channels,
 or bidirectional pegs.
 
+===Examples===
+
+====Escrow with Timeout====
+
+An escrow that times out automatically 30 days after being funded can be
+established in the following way. Alice, Bob and Escrow create a 2-of-3
+address with the following redeemscript.
+
+    IF
+        2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIGVERIFY
+    ELSE
+        <LOCKTIME_THRESHOLD + 30*24*60*60> CHECKSEQUENCEVERIFY DROP
+        <Alice's pubkey> CHECKSIGVERIFY
+    ENDIF
+
+At any time funds can be spent using signatures from any two of Alice, 
+Bob or the Escrow.
+
+After 30 days Alice can sign alone.
+
+The clock does not start ticking until the payment to the escrow address
+confirms. 
+
+
+====Payment Channel Revokation====
+
+Scriptable relative locktime provides a predictable amount of time to respond in
+the event a counterparty broadcasts a revoked transaction: Absolute locktime
+necessitates closing the channel and reopen it when getting close to the timeout,
+whereas with relative locktime, the clock starts ticking the moment the
+transactions confirms in a block. It also provides a means to know exactly how
+long to wait (in number of blocks) before funds can be pulled out of the channel
+in the event of a noncooperative counterparty.
+
+
+====Hash Time-Locked Contracts====
+
+Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which
+is required for lightning network payment channels. The scheme requires both
+CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY to enforce HTLC timeouts and
+revokation.
+
 
 ==Specification==
 
@@ -155,49 +197,6 @@ semantics and detailed rationale for those semantics.
     }
 
 
-==Examples==
-
-===Escrow with Timeout===
-
-An escrow that times out automatically 30 days after being funded can be
-established in the following way. Alice, Bob and Escrow create a 2-of-3
-address with the following redeemscript.
-
-    IF
-        2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIGVERIFY
-    ELSE
-        <LOCKTIME_THRESHOLD + 30*24*60*60> CHECKSEQUENCEVERIFY DROP
-        <Alice's pubkey> CHECKSIGVERIFY
-    ENDIF
-
-At any time funds can be spent using signatures from any two of Alice, 
-Bob or the Escrow.
-
-After 30 days Alice can sign alone.
-
-The clock does not start ticking until the payment to the escrow address
-confirms. 
-
-
-===Payment Channel Revokation===
-
-Scriptable relative locktime provides a predictable amount of time to respond in
-the event a counterparty broadcasts a revoked transaction: Absolute locktime
-necessitates closing the channel and reopen it when getting close to the timeout,
-whereas with relative locktime, the clock starts ticking the moment the
-transactions confirms in a block. It also provides a means to know exactly how
-long to wait (in number of blocks) before funds can be pulled out of the channel
-in the event of a noncooperative counterparty.
-
-
-===Hash Time-Locked Contracts===
-
-Hashed Timelock Contracts (HTLCs) can be used to create chains of payments which
-is required for lightning network payment channels. The scheme requires both
-CHECKSEQUENCEVERIFY and CHECKLOCKTIMEVERIFY to enforce HTLC timeouts and
-revokation.
-
-
 ==Reference Implementation==
 
 A reference implementation is provided in the following git repository: