CashChannels: Recurring Payments for Bitcoin Cash

CashChannels let users pre-approve future transactions, valued in any currency, to another person or company.

Once the spender has authorized a payment – and the specified time has passed – the receiver can create the transaction without the spender having to open their wallet. CashChannels automatically ensure the payment is correct, and spenders have full control over their money at all times.

Recurring Payments with Bitcoin

Recurring payments have always been difficult with bitcoin. While it’s always been possible for users to pre-sign transactions for a future date, this can only be done if:

• all of the funds are already in the user’s wallet,
• the user avoids moving the funds (even if the user has enough funds, making a new transaction will often require that the wallet invalidates pending transactions), and
• the value is denominated in bitcoin.

For example: for a $10/month subscription, the spender would need $60 worth of bitcoin to pre-sign 6 months of subscription payments (and they can’t move the $60). If the market value of bitcoin fell, the user would need to re-sign each transaction to increase the payment. If the value of bitcoin rose, the user’s wallet would need to move the funds to invalidate the previously signed transactions, then it would need to re-sign new transactions with a smaller payment amount.

This technique almost always requires user interaction before a payment processes, so these kinds of pre-signed transactions have never really been useful or common.

Recurring Payments with CashChannels

CashChannels allow much more flexibility with recurring payments. Unlike pre-signed transactions, the spender does not need to have funds on hand to preauthorize CashChannel payments.

The spender authorizes a payment by signing a specially-formatted Payment Authorization message. They then send the authorization to the receiver, who holds it until the payment time. At or after the payment time, the receiver can use the authorization to create a single transaction from the channel for the correct amount.

Payment Authorizations

When creating a payment authorization, the spender’s wallet specifies:

• Payment Amount in terms of any currency, like BCH, USD, or XAU. (See section below on Rate Oracles.)
• Denominating Asset — the currency or asset in which the payment amount is specified.
• Payment Time at which the authorization may be used by the receiver to pull funds from the channel.
• Maximum Authorized Satoshis, which is the maximum value (in terms of BCH) that this authorization allows (If the user sets this close to the market value of the payment amount, and that market value rises significantly, the payment is limited to this maximum.)
• Channel Identifier and Payment Number, which ensure the authorization can only be used once for the correct channel.

Channel Balances

Unlike pre-signed transactions, it’s possible for spenders to add or withdraw funds from a channel at any time without interrupting future payments.

Much like debit accounts, each channel holds a balance. Receivers can use payment authorizations to pull from this balance at the approved time, and the channel ensures that transactions return the correct value to the channel.

Spenders need only to ensure they have enough money in the channel to make upcoming payments. From a subscription service’s perspective, CashChannels are a complete replacement for debit cards.

The spender can easily close the channel with their own key at any time, moving the balance to a new channel or another address.

Using an Exchange Rate Oracle

If the payment authorization is specified in a currency other than BCH, the spender’s wallet also selects a Rate Oracle, a partially-trusted entity which determines the market value of the denominating asset at payment time.

The Rate Oracle’s signed message is used by the channel to determine the exact BCH amount of the payment. To be valid, the amount must be below the Maximum Authorized Satoshis specified in the payment authorization.

Depending on the relationship between the spender and the receiver, the receiver (or a party contracted by the receiver) might also serve as the rate oracle. (Relying on the “discipline of constant dealings”. E.g. if the spender consistently disagrees with the exchange rates, they can lower their maximums or stop doing business with the receiver.)

In a business scenario, the payment processor will likely be the rate oracle.

Preserving User Privacy with CashChannels

Like all bitcoin payments, the value, frequency, and source of funds used in a CashChannel payment are public record (on-chain). Because the on-chain contract enforces the behavior of channels, it’s easy to “follow the money” and see the activity and balance of a channel.

For privacy and security, a new CashChannel should be created for every person or company the spender wants to pay, and channels should be regularly closed and recreated. Depending on the spender’s preference, this could happen every 6 months, or it could happen after every payment.

Wallets should always and automatically use privacy technologies like CashShuffle before funding channels and after closing them. With a well-designed wallet, CashChannel privacy is similar to standard (P2PKH) transactions.

Technical Details

The first draft of a CashChannels authentication template is now available. In Bitauth IDE, you can inspect each script used by the template, including a line-by-line evaluation of the unlocking and locking bytecode. The template also includes detailed technical descriptions for all entities and variables.

Wallets which support Bitauth templates can import this template to automatically support creating and using CashChannels. It’s recommended that CashChannels only be used on testnet until their security has been thoroughly reviewed.

Transaction Sizes

A CashChannel payment currently has a total input size of 846 bytes. CashChannel outputs are P2SH, so they are always 22 bytes. In total, a typical CashChannel transaction should be about 900 bytes, requiring a fee of 900 satoshis (~0.2 cents USD).

With some improvements to the BCH VM (making transaction signing serialization elements available via opcodes), about 400 bytes can be trimmed from the input sizes, bringing normal transactions down to around 500 bytes (close to the size of a small multi-signature transaction). BCH-only CashChannels (no rate oracle) also save about 100 bytes.

Interaction with SLP

Because Simple Ledger Protocol requires the first output of a transaction to be the OP_RETURN SLP message, this template currently can’t be used in an SLP transaction. However, it’s possible to modify this template to support reading the channel output from another index by reading the BitcoinVarInt of each output, converting them to Script Numbers with bitwise math, and stepping through to validate the output at a certain index. To use CashChannels to preauthorize an actual SLP transfer, it will also be necessary to perform some additional validation on the SLP message. The locking bytecode currently uses 90 operations, so these changes should be well within the 201 limit.

Get Involved

If you’re interested in adding CashChannels to your wallet, have ideas for improving or optimizing the template, or if you have other questions or suggestions, you can find me on Twitter or comment on the Gist.

Thanks for reading!