From 5d0ae1caa36b3550af695c1b75082a1436f4215e Mon Sep 17 00:00:00 2001 From: Peter Todd 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