From 748f33ccfb88f904287a076abffc6469bc097995 Mon Sep 17 00:00:00 2001
From: BtcDrak <btcdrak@gmail.com>
Date: Sun, 4 Oct 2015 19:23:12 +0100
Subject: Better formatting

---
 bip-0112.mediawiki | 16 +++++++---------
 1 file changed, 7 insertions(+), 9 deletions(-)

(limited to 'bip-0112.mediawiki')

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index eefd627..425c966 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -51,12 +51,10 @@ 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===
 
+===Contracts With Expiration Deadlines===
 
-====Contracts With Expiration Deadlines====
-
-=====Escrow with Timeout=====
+====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
@@ -78,7 +76,7 @@ The clock does not start ticking until the payment to the escrow address
 confirms. 
 
 
-====Retroactive Invalidation====
+===Retroactive Invalidation===
 
 In many instances, we would like to create contracts that can be revoked in case
 of some future event. However, given the immutable nature of the blockchain, it
@@ -98,11 +96,11 @@ honoring the original contract.
 
 Some more specific applications of this idea:
 
-=====Hash Time-Locked Contracts=====
+====Hash Time-Locked Contracts====
 
 Hash Time-Locked Contracts (HTLCs) provide a general mechanism for offchain contract negotiation. An execution pathway can be made to require knowledge of a secret (a hash preimage) that can be presented within an invalidation time window. By sharing the secret it is possible to guarantee to the counterparty that the transaction will never be broadcast since this would allow the counterparty to claim the output immediately while one would have to wait for the time window to pass. If the secret has not been shared, the counterparty will be unable to use the instant pathway and the delayed pathway will be used instead.
 
-=====Bidirectional Payment Channels=====
+====Bidirectional Payment Channels====
 
 Scriptable relative locktime provides a predictable amount of time to respond in
 the event a counterparty broadcasts a revoked transaction: Absolute locktime
@@ -113,7 +111,7 @@ long to wait (in number of blocks) before funds can be pulled out of the channel
 in the event of a noncooperative counterparty.
 
 
-=====Lightning Network=====
+====Lightning Network====
 
 The lightning network extends the bidirectional payment channel idea to allow for payments to be routed over multiple bidirectional payment channel hops.
 
@@ -217,7 +215,7 @@ secret.
 See the [https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf Deployable Lightning] paper.
 
 
-=====2-Way Pegged Sidechains=====
+====2-Way Pegged Sidechains====
 
     OP_IF
         lockTxHeight <lockTxHash> nlocktxOut [<workAmount>] reorgBounty Hash160(<...>) <genesisHash> OP_REORGPROOFVERIFY
-- 
cgit v1.2.3

