How to sign a partial CKB transaction to limit the fee and burned UDT

[doitian]

In this thread, I want to raise an issue about #3608 and post some questions for open discussions.

The Problem

Focus on this user story—Alice wants to send Bob 11 CKB and pay 1 CKB as the transaction fee. Because 10 CKB is not enough to create a cell, Bob has to provide an input as well.

Alice and Bob both have to sign the transaction. If Bob is a merchant, he must be online to receive payments.

CKB Anyone-Can-Pay Lock is the state-of-the-art to allow Bob receiving payments without interactions, which does not require owner signature when the transaction increases the locked value.

Alice can commit the transaction to the chain alone. But she must be able to find a live ACP cell owned by Bob. If there are many payments to Bob, payers have to retry when others have spent the ACP cell.

How Partial Signed Transaction Can Help

Alice Allows ACP Input Replacement

Alice can sign the transaction that it can use any ACP cell from Bob, similar to the Bitcoin proposal SIGHASH_ANYPREVOUT. Anyone can find an ACP cell owned by Bob and complete the transaction without interactions from Alice.

But Alice does not know the APC cell balance in advance. If she leaves the ACP balance unsigned in both inputs and outputs, it's possible to create a transaction like this:

Alice could require Bob to sign the whole transaction. She sets Bob's input cell lock script to secp256k1_blake160_sighash_all and sign the partial transaction. To complete the transaction, Bob has to review and sign, which requires Bob online again.

How Alice can sign such a transaction that Bob will receive exactly 10 CKB, or at least 10 CKB?

Depending on whether we prefer a complex lock script or a complex transaction structure, there are two possible solutions.

• Either the partial signing lock could sign the difference of some fields,
• Or there is a script to check the difference, and Alice ensures the script will execute by signing some fields in the transaction.

The scenario above is about CKB native token, the solution should cover UDT and any user defined asset as well.

Allowing input replacement makes recreating transaction easier, but it does not resolve the problem that all the payments competing for the ACP cells. However, Bob could run a service or delegate to a third-party service. The service can queue the received open transactions and avoid the conflicts.

Aggregation

Say we already have a solution that Alice can sign a partial transaction that Bob must receive a specific amount of payments. Can we do better to aggregate many payments into one CKB transaction?

Alice allowed 10 CKB, and Carol allowed 100 CKB. Bob even does not need to provide an input. But how the partial signing lock script knows that the output for Bob is the sum of two partial transactions?

[doitian]

I am writing some throughs in my mind. I'll post later and here is a summary.

We can create a script named assert. The script declares a list of assertions in args or witness. When the script runs, it ensures that all the declared assertions hold. Now we can add the script and the assertion about how many Bob should receive to the partial transaction and sign.

The pros, we don't need to add the logic to the partial signing script. The cons, the transaction structure is complex. We have to decide which cell to add the assert script, as type script or lock script, in inputs or outputs.

[doitian]

This is a link to open the last image in Excalidraw, in case you want to sketch on the images.

[janx]

I think it's the "partial signing lock"'s responsibility to make sure Bob receives certain amounts.

If we consider Alice's open transaction as a "payment request", a "partial sign lock" should:

• express Alice's payment intent, if part of the intent cannot be inferred by inputs/output, it should be explicitly expressed in other ways, e.g. witness;
• sign this payment request, so its origin can be authenticated and its content cannot be modified;

The problem here is the payment amount cannot be easily inferred from inputs/outputs, because the amount to pay and tx fee mix together. So it's necessary to have an "amount" field somewhere (e.g. in witness).

Then different use cases would require different "partial sign lock". In other words, we need "DEX open lock", "Payment open lock", etc.. A "X open lock" is a user signed request (request to bid/sell in DEX, request to pay in Payment) to be matched with another user's or matcher's "X open lock". Based on open transaction there will be X sub-protocols - e.g. payment sub-protocol and DEX sub-protocol.

Such a payment sub-protocol will set the standards/convention of witness layout, so a matcher knows how to analyse the payment intent and aggregate two payments (Alice -> Bob, Charlie -> Bob).

For this purpose, it seems open transaction function should be implemented as a library, for sub-protocol locks' reference and integrate.

[doitian]

An idea received from @quake

If Bob can afford to keep creating fixed value cells, say ACP cells with 100 CKB. Payers can just sign against input balance 100, and output balance 100 + received - fee.

[doitian]

Another idea, I call it ACP Take All lock script. It is an ACP lock, and also requires that the owner takes all the transferred value in the transaction.