1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-04 03:03:53 +01:00

Refer to "Payment Channels" rather than "Micro-Payment Channels"

More generic terminology.
This commit is contained in:
Peter Todd 2015-11-13 12:14:19 -05:00
parent f3d94433e2
commit f6a5bf2c5e
No known key found for this signature in database
GPG key ID: C085F21CE7F4B9DC

View file

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