From 5d0ae1caa36b3550af695c1b75082a1436f4215e Mon Sep 17 00:00:00 2001
From: Peter Todd <pete@petertodd.org>
Date: Fri, 13 Nov 2015 12:24:27 -0500
Subject: Reword motivation section

Previous wording was very confusing now that most people will associate
payment channels with CLTV-based payment channels rather than Jeremy
Spilman style payment channels.
---
 bip-0065.mediawiki | 20 ++++++++------------
 1 file changed, 8 insertions(+), 12 deletions(-)

(limited to 'bip-0065.mediawiki')

diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
index 6163b90..b48fa75 100644
--- a/bip-0065.mediawiki
+++ b/bip-0065.mediawiki
@@ -32,18 +32,14 @@ remains unspendable.
 
 ==Motivation==
 
-The nLockTime field in transactions makes it possible to prove that a
-transaction output can be spent in the future: a valid signature for a
-transaction with the desired nLockTime can be constructed, proving that it is
-possible to spend the output with that signature when the nLockTime is reached.
-An example where this technique is used is in payment channels, where the
-nLockTime field proves that should the receiver vanish the sender is guaranteed
-to get all their escrowed funds back when the nLockTime is reached.
-
-However, the nLockTime field is insufficient if you wish to prove that a
-transaction output ''cannot'' be spent until some time in the future, as there
-is no way to prove that the secret keys corresponding to the pubkeys controlling
-the funds have not been used to create a valid signature.
+The nLockTime field in transactions can be used to prove that it is
+''possible'' to spend a transaction output in the future, by constructing a
+valid transaction spending that output with the nLockTime field set.
+
+However, the nLockTime field can't prove that it is ''impossible'' to spend a
+transaction output until some time in the future, as there is no way to know if
+a valid signature for a different transaction spending that output has been
+created.
 
 
 ===Escrow===
-- 
cgit v1.2.3

