mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-18 21:35:13 +01:00
Code Issues Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Jeff Garzik 2015-11-13 12:44:59 -05:00
commit d0cab0379a
Failed to extract signature
1 changed files with 16 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

36
bip-0065.mediawiki
View File

@ -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==