diff options
Diffstat (limited to 'bip-0065.mediawiki')
| -rw-r--r-- | bip-0065.mediawiki | 8 |
1 files 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== |