From cc90614074444d1bff1a60e1511c051e336eaab8 Mon Sep 17 00:00:00 2001
From: Eric Lombrozo <elombrozo@gmail.com>
Date: Tue, 17 Nov 2015 07:37:03 -0500
Subject: BIP-0112 minor revision to text.

---
 bip-0112.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'bip-0112.mediawiki')

diff --git a/bip-0112.mediawiki b/bip-0112.mediawiki
index e1a186f..f79fd32 100644
--- a/bip-0112.mediawiki
+++ b/bip-0112.mediawiki
@@ -85,9 +85,9 @@ of some future event. However, given the immutable nature of the blockchain, it
 is practically impossible to retroactively invalidate a previous commitment that
 has already confirmed. The only mechanism we really have for retroactive
 invalidation is blockchain reorganization which, for fundamental security
-reasons, is designed to be very hard and very expensive to deliberately pull off.
+reasons, is designed to be very hard and very expensive to do.
 
-Despite this limitation, we do have a way to provide something functionally similar
+Despite this limitation, we do have a way to provide something functionally similar to retroactive invalidation while preserving irreversibility of past commitments
 using CHECKSEQUENCEVERIFY. By constructing scripts with multiple branches of
 execution where one or more of the branches are delayed we provide
 a time window in which someone can supply an invalidation condition that allows the
-- 
cgit v1.2.3

