How It Works In Short
This explanation is for quick understanding. Detail comes later.
For example, when Alice wants to send 100 Satoshi many times to Bob,
1: Create Alice and Bob’s 2-of-2 multisig address
Funding the channel (ex. 1000 satoshis):
2: Alice deposits 1000 satoshis in 2-of-2 multisig address BUT HOLDS THE TRANSACTION. DOES NOT BROADCAST.
3: Set time limit refund of 1000 satoshis sent in #2 to Alice by using nLockTime and get Bob to sign it.
4: Once Alice receives the signed nLockTime from Bob, Alice broadcasts the 1000 satoshis to 2-of-2 mutisig address from #2.
Spending money in-channel (ex. 100 satoshis):
5: Set time limit refund of 900 satoshis with 1 output to Bob with 100 satoshis. The nLockTime should be EARLIER than the funding refund from #3. Bob receives the signed transaction from Alice and holds on to it. (does not broadcast)
6: Bob can always redeem the 100 satoshi transaction EARLIER than Alice can redeem hers in the event of Alice being a thief. Also, Alice can always get her money back minus any money she agreed to send in the micropayment channel. By Bob or Alice broadcasting their transactions.
Settling channel:
7: Alice signs a transaction with no nLockTime and the proper outputs going to Alice and Bob. Bob checks that those are correct, and signs then broadcasts. The 2-of-2 multisig is now empty.
Pros and Cons
Pros
- Faster confirmations
- Lower fees
- Less blockchain transactions (off-chain)
Cons
- You have to deposit some BTC first
- More complex
Prerequisite Knowledge
- How Bitcoin transaction works
- How Bitcoin script works
- nLockTime
- Multi-sigunature
- BIP
How It Works In Detail
Quote from Bitcoin Wiki
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.
Create a public key (K1). Request a public key from the server (K2).
Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server’s private key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.
Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don’t sign it, and provide the unsigned transaction to the server. By convention, the output script is “2 K1 K2 2 CHECKMULTISIG”
The server signs T2 using its private key associated with K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).
The client verifies the servers signature is correct and aborts if not.
The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.
The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.
The server verifies the output to itself is of the expected size and verifies the client’s provided signature is correct.
When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server’s output and less to its own. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.
Quote from
- Bitcoin Wiki: Example 7: Rapidly-adjusted (micro)payments to a pre-determined party
Developer Guide – Bitcoin at bitcoin.org
Documents
- Jeremy Spilman Style Micropayment Channels
- Re: [Bitcoin-development] Anti DoS for tx replacement
- This style micropayment channel is descripved in this Peter Todd’s BIP proposal.
- bips/bip-checklocktimeverify.mediawiki at checklocktimeverify · petertodd/bips
- Mike Hearn’s Blog:
- Original idea?: Instant TX for established business relationships (need replacements/nLockTime)
-
UC Berkeley: Bitcoin Micropayment Channels | UC Berkeley School of Information
-
blog: How Bitcoin Micropayment Channels Work – Toshiro Nishimura
Use Cases
-
Bitcoinj: Java
- Metercoin: Node.js
- YouTube: Lightning Network
- Decentralized Exchange, Coinffeine uses micropayment channel.
- Amiko Pay
- off-blockchain Bitcoin transactions
- Amiko Pay
Startup
- Strawpay – cheap and secure micropayments : Bitcoin
- Stroem (Ström) Protocol
- Quote from Mike’s article: “Stroem works with the Bitcoin protocol of today and accepts the caveats whereas Lightning doesn’t.”
- Presentation by Jarl Fransson (Strawpay) at ScalingBitcoin stroem-payment-channels
Library
Thanks
Thank you for the review to
- Jonathan Underwood
