mirror of
https://github.com/bitcoin/bips.git
synced 2025-03-03 10:47:00 +01:00
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.
This commit is contained in:
parent
c912e616d3
commit
5d0ae1caa3
1 changed files with 7 additions and 11 deletions
|
@ -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.
|
||||
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 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.
|
||||
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===
|
||||
|
|
Loading…
Add table
Reference in a new issue