summaryrefslogtreecommitdiff
path: root/bip-0112.mediawiki
diff options
context:
space:
mode:
authorEric Lombrozo <elombrozo@gmail.com>2015-11-17 07:37:03 -0500
committerEric Lombrozo <elombrozo@gmail.com>2015-11-17 07:39:54 -0500
commitcc90614074444d1bff1a60e1511c051e336eaab8 (patch)
tree0ab8661715f8d0e185898ada8138dce2b359a148 /bip-0112.mediawiki
parent989f276dcbdb0317dd795fe4a64a0c1416e1bb1c (diff)
BIP-0112 minor revision to text.
Diffstat (limited to 'bip-0112.mediawiki')
-rw-r--r--bip-0112.mediawiki4
1 files changed, 2 insertions, 2 deletions
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