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 pull request #160 from mruddy/bip65

Browse Source 
BIP65: add sections on ability to freeze funds and implementations
This commit is contained in:
Wladimir J. van der Laan 2015-06-24 17:29:19 +00:00
commit 11d8610907
1 changed files with 28 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
bip-0065.mediawiki
View File

@ -40,7 +40,7 @@ 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.
However the nLockTime field is insufficient if you wish to prove that
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.
@ -60,7 +60,7 @@ either Alice or Bob to steal the funds illegitimately. Equally Lenny may prefer
not to have immediate access to the funds to discourage bad actors from
attempting to get the secret keys from him by force.
However with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of
However, with CHECKLOCKTIMEVERIFY the funds can be stored in scriptPubKeys of
the form:
IF
@ -86,12 +86,12 @@ funds with the following scriptSig:
There exist a number of protocols where a transaction output is created that
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
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,
replacing the interactive setup with a non-interactive setup, and additionally,
making transaction mutability a non-issue.
making transaction mutability (aka malleability) a non-issue.
====Two-factor wallets====
@ -172,6 +172,17 @@ sufficiently far into the future that large miners profitably can't sell the
sacrifices at a discount.
===Freezing Funds===
In addition to using cold storage, hardware wallets, and P2SH multisig outputs
to control funds, now funds can be frozen in UTXOs directly on the blockchain.
With the following scriptPubKey, nobody will be able to spend the encumbered
output until the provided expiry time. This ability to freeze funds reliably may
be useful in scenarios where reducing duress or confiscation risk is desired.
<expiry time> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG
===Replacing the nLockTime field entirely===
As an aside, note how if the SignatureHash() algorithm could optionally cover
@ -276,9 +287,21 @@ time.
PayPub - https://github.com/unsystem/paypub
Jeremy Spilman Micropayment Channels - http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg02028.html
Jeremy Spilman Micropayment Channels - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html
==Implementations==
Python / python-bitcoinlib
- https://github.com/petertodd/checklocktimeverify-demos
JavaScript / Node.js / bitcore
- https://github.com/mruddy/bip65-demos
==Copyright==
This document is placed in the public domain.