From f3d94433e252ad9bc56edd4485c3da7d5e0d3d52 Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Fri, 13 Nov 2015 12:13:03 -0500 Subject: Minor: fix wording --- bip-0065.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index ed87478..e8c56f9 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -168,7 +168,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. -- cgit v1.2.3 From f6a5bf2c5ebc29aea49dbbfaf78fde56cf0e9584 Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Fri, 13 Nov 2015 12:14:19 -0500 Subject: Refer to "Payment Channels" rather than "Micro-Payment Channels" More generic terminology. --- bip-0065.mediawiki | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index e8c56f9..c9f78f6 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -36,7 +36,7 @@ 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 +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. @@ -121,9 +121,9 @@ 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 @@ -307,7 +307,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== -- cgit v1.2.3 From abeaa1be10c2447d3c7b461582674a2b698cc50b Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Fri, 13 Nov 2015 12:17:23 -0500 Subject: Use the term "malleability" rather than "mutability" --- bip-0065.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index c9f78f6..6563010 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -89,9 +89,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==== @@ -128,7 +128,7 @@ Jeremy Spilman style payment channels first setup a deposit controlled by 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. -- cgit v1.2.3 From c912e616d383d3ebae9d3a2932d5fd193978ff9d Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Fri, 13 Nov 2015 12:19:53 -0500 Subject: Clearer wording --- bip-0065.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index 6563010..6163b90 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 -- cgit v1.2.3 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(-) 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