From 4c04b67f7c0259538720eb3ffbe2f2940dce434b Mon Sep 17 00:00:00 2001 From: jl2012 Date: Wed, 29 Apr 2015 17:33:05 +0800 Subject: Dummy 0 in scriptSig for CHECKMULTISIG There should be a dummy 0 in the scriptSig for CHECKMULTISIG --- bip-0065.mediawiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'bip-0065.mediawiki') diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index fb22ace..a780b65 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -74,12 +74,12 @@ the form: At any time the funds can be spent with the following scriptSig: - 0 + 0 0 After 3 months have passed Lenny and one of either Alice or Bob can spend the funds with the following scriptSig: - 1 + 0 1 ===Non-interactive time-locked refunds=== -- cgit v1.2.3 From 79f6ed1854ef959841b832dccb674d27c35e3b6b Mon Sep 17 00:00:00 2001 From: mruddy Date: Mon, 22 Jun 2015 00:01:03 -0400 Subject: add section on ability to freeze funds, updated link to bitcoin-dev list, and added section on implementations --- bip-0065.mediawiki | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) (limited to 'bip-0065.mediawiki') diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index 5c687c6..3667f4c 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -171,6 +171,15 @@ assuming miners behave optimally and rationally) but only at a time 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. + + CHECKLOCKTIMEVERIFY DROP DUP HASH160 EQUALVERIFY CHECKSIG ===Replacing the nLockTime field entirely=== @@ -271,14 +280,23 @@ Thanks goes to Gregory Maxwell for suggesting that the argument be compared against the per-transaction nLockTime, rather than the current block height and time. - ==References== 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. + -- cgit v1.2.3 From 5d0d854cdd5a69fa7d8b7ab6f557da4189cc5799 Mon Sep 17 00:00:00 2001 From: mruddy Date: Tue, 23 Jun 2015 17:34:41 -0400 Subject: minor comma, spacing, and wording adjustments --- bip-0065.mediawiki | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) (limited to 'bip-0065.mediawiki') diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index 3667f4c..02de20b 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -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==== @@ -171,6 +171,7 @@ assuming miners behave optimally and rationally) but only at a time 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 @@ -181,6 +182,7 @@ be useful in scenarios where reducing duress or confiscation risk is desired. CHECKLOCKTIMEVERIFY DROP DUP HASH160 EQUALVERIFY CHECKSIG + ===Replacing the nLockTime field entirely=== As an aside, note how if the SignatureHash() algorithm could optionally cover @@ -280,12 +282,14 @@ Thanks goes to Gregory Maxwell for suggesting that the argument be compared against the per-transaction nLockTime, rather than the current block height and time. + ==References== PayPub - https://github.com/unsystem/paypub Jeremy Spilman Micropayment Channels - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html + ==Implementations== Python / python-bitcoinlib @@ -296,6 +300,7 @@ JavaScript / Node.js / bitcore - https://github.com/mruddy/bip65-demos + ==Copyright== This document is placed in the public domain. -- cgit v1.2.3