Merge #241 from branch '2015-11-13-bip65-wording-fixes' of git://github.com/petertodd/bips

1 files changed, 16 insertions, 20 deletions

diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki
index ed87478..b48fa75 100644
--- a/bip-0065.mediawiki
+++ b/bip-0065.mediawiki
@@ -18,8 +18,8 @@ some point in the future.
 
 CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode. When executed it
 compares the top item on the stack to the nLockTime field of the transaction
-containing the scriptSig. If that top stack item is greater than the transaction
-nLockTime the script fails immediately, otherwise script evaluation continues
+containing the scriptSig. If that top stack item is greater than the transaction's
+nLockTime field the script fails immediately, otherwise script evaluation continues
 as though a NOP was executed.
 
 The nLockTime field in a transaction prevents the transaction from being mined
@@ -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 micro-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===
@@ -89,9 +85,9 @@ requires the co-operation of both parties to spend the output. To ensure the
 failure of one party does not result in the funds becoming lost, refund
 transactions are setup in advance using nLockTime. These refund transactions
 need to be created interactively, and additionaly, are currently vulnerable to
-transaction mutability. CHECKLOCKTIMEVERIFY can be used in these protocols,
+transaction malleability. CHECKLOCKTIMEVERIFY can be used in these protocols,
 replacing the interactive setup with a non-interactive setup, and additionally,
-making transaction mutability (aka malleability) a non-issue.
+making transaction malleability a non-issue.
 
 
 ====Two-factor wallets====
@@ -121,14 +117,14 @@ Now the user is always able to spend their funds without the co-operation of
 the service by waiting for the expiry time to be reached.
 
 
-====Micropayment Channels====
+====Payment Channels====
 
-Jeremy Spilman style micropayment channels first setup a deposit controlled by
+Jeremy Spilman style payment channels first setup a deposit controlled by
 2-of-2 multisig, tx1, and then adjust a second transaction, tx2, that spends
 the output of tx1 to payor and payee. Prior to publishing tx1 a refund
 transaction is created, tx3, to ensure that should the payee vanish the payor
 can get their deposit back. The process by which the refund transaction is
-created is currently vulnerable to transaction mutability attacks, and
+created is currently vulnerable to transaction malleability attacks, and
 additionally, requires the payor to store the refund. Using the same
 scriptPubKey from as in the Two-factor wallets example solves both these issues.
 
@@ -168,7 +164,7 @@ non-trivial, and even the best existing technqiue - announce-commit sacrifices
 - could encourage mining centralization. CHECKLOCKTIMEVERIFY can be used to
 create outputs that are provably spendable by anyone (thus to mining fees
 assuming miners behave optimally and rationally) but only at a time
-sufficiently far into the future that large miners profitably can't sell the
+sufficiently far into the future that large miners can't profitably sell the
 sacrifices at a discount.
 
 
@@ -307,7 +303,7 @@ time.
 
 PayPub - https://github.com/unsystem/paypub
 
-Jeremy Spilman Micropayment Channels - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html
+Jeremy Spilman Payment Channels - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html
 
 
 ==Implementations==