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

More generic terminology.

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