[DRAFT] Analyze Scenarios of CKB Open Transaction

[doitian]

Synopsis

CKB Open Transaction is a format to describe the partial transaction. It does not add new features, but can improve the user experience in many scenarios. I spend last two weeks analyzing these scenarios to see how CKB Open Transaction can help in details.

Payment

In payment scenarios, participants transfer value by constructing a CKB transaction. Payers add their UTXOs cells to the transaction as inputs. Usually they also have outputs to keep the change. Payees own the outputs which carry the value transferred to them.

CKB requires cell capacity to cover the cell storage overhead. This means that the cell locked by standard secp256k1 script must have at least 61 CKB. When the paid CKB amount is less than 61, which is common to transfer user defined assets, the payee has to provide an input as well.

When payee has to provide the input, payers cannot create the transaction on their own. Because the transaction requires signatures from both payee and payer.

Payment is so fundamental and important that the community has created several standards to address this issue.

Anyone-Can-Pay (ACP, RFC26) is a special lock that payee does not need to sign the transaction to receive payment. But payers have to find the live ACP cell owned by the payee. It is impractical and sometimes impossible. Also, if multiple payments use the same ACP cell as input, they are conflict with each other and only one will succeed; the others have to re-create the transaction.

Cheque (RFC39) tackles this issue via a two-step commitment. Payers lock the transferred value in the Cheque cell, while the payee claims the value and returns the extra CKB value back to payers.

Let's see how the partial transaction can help.

Payment Solution A

This solution adopts ACP but leaves the out point to the input ACP cell unsigned, so any ACP cell owned by the payee is a valid candidate. The payer does not need to re-sign on double spent conflict. Anyone can help to find a valid ACP cell and re-create the transaction.

However, payers must sign the input and output CKB capacity of the cells owned by the payee. Otherwise, miners can create a transaction that only transfers a small amount to the payee and leaves the remaining as transaction fee. But payers do not know the ACP cell balance in advance.

There are three ways to work around this:

1. Sign the ACP cell with the fixed balance. This means that the payee has to create the ACP cells with the specified balance.
2. The payee uses a lock script requiring signing the whole transaction. To complete the transaction, the payee runs a service to collect the pending payments, create a transaction with correct transferred value, and sign the transaction.
3. Use the lock Take-All-And-Then

Payment Solution B

Solution B is based on Take-All-And-Then.

The payer signs the transaction such that:

• The first input is any cell owned by the payee locked by Take-All-And-Then.
• The first output is any cell owned by the payee.
• The payer input cell can be at any position except the first.
• The payer output change cell must be in the same position as the input cell.

Such partial signing schema allows the payee to merge several open transactions into one CKB transaction.

Coin Join

Coin Join anonymizes transactions online. In the Coin Join transaction, every output cell has the same balance, which makes the origin of the cells difficult to trace.

We cannot use partial signature to sign only the owned input and output cells, which breaks the output cell anonymity.

A simply solution is combining the partial transactions first and then asking all participants to sign the whole transaction. The transaction cannot complete if any participant refuses to sign the transaction. Dividing participants into overlapping sets can mitigate this, because it only requires signatures from a sub-set of all the participants.

Multi-Party Signing

Multi-Party Signing is just the second step of Coin Join.

dApp Specific Scenarios

I'll delve into some dApps in the following weeks, including:

• CoTA
• Force Bridge Deposit