Skip to content

Instantly share code, notes, and snippets.

@martindale
Created February 27, 2014 18:34
Show Gist options
  • Select an option

  • Save martindale/9256150 to your computer and use it in GitHub Desktop.

Select an option

Save martindale/9256150 to your computer and use it in GitHub Desktop.
General flow for micropayment channels in Bitcoin.
  1. Create a public key (K1). Request a public key from the server (K2).
  2. 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 public 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.
  3. 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"
  4. The server signs T2 using its public key 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).
  5. The client verifies the servers signature is correct and aborts if not.
  6. 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.
  7. 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.
  8. The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.
  9. 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 ow. 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment