diff options
| author | Eric Lombrozo <elombrozo@gmail.com> | 2015-11-17 07:37:03 -0500 |
|---|---|---|
| committer | Eric Lombrozo <elombrozo@gmail.com> | 2015-11-17 07:39:54 -0500 |
| commit | cc90614074444d1bff1a60e1511c051e336eaab8 (patch) | |
| tree | 0ab8661715f8d0e185898ada8138dce2b359a148 /bip-0112.mediawiki | |
| parent | 989f276dcbdb0317dd795fe4a64a0c1416e1bb1c (diff) | |
| download | bips-cc90614074444d1bff1a60e1511c051e336eaab8.tar.xz | |
BIP-0112 minor revision to text.
Diffstat (limited to 'bip-0112.mediawiki')
| -rw-r--r-- | bip-0112.mediawiki | 4 |
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 |