feat(rgbpp): support for batch transferring of RGBPP XUDT assets

[ShookLyngs]

Changes

• Add buildRgbppTransferAllTxs() API to generate one or more BTC/CKB transaction groups for transferring the entire amount of a specific type of RGBPP XUDT asset from one or more BTC addresses to a recipient
• Add sendRgbppTxGroups() API for sending BTC/CKB transaction groups to the BtcAssetsApi

TODOs

• Base coding
• Testing
  • Prepare mocked tests @ShookLyngs
  • Functional testing @Dawn-githup
• Update docs (README of rgbpp)
• Update examples? (no place for the example)

[ShookLyngs]

Mocked a test for the transfer-all-of-an-rgbpp-xudt-asset feature with @Dawn-githup:

• Transfer all amount of a specific RGBPP XUDT asset XTT, from Alice to Bob
• Alice holds 41 L2 cells bound to the same L1 output, the total amount is 41 XTT
• Alice holds another 50 L2 cells, each bound to an individual L1 output, the total amount is 500 XTT

The expected result:

• Alice transfers 500 XTT to Bob in 2 transactions because each CKB can contain up to 40 RGBPP cells
• The 41 cells with total value of 41 XTT should be excluded during the transfer process, because too much L2 cells have been bound to a single L1 output, while each CKB transaction can include up to 40 RGBPP cells
• The L1 fees should be paid with the L1 RGBPP outputs because the fee rate is low

The actual transaction groups generated from the process:

• 0da44932270292fd3a4165f1f7ab81abf69b951e1e7d3b5c012e00a291c6b222
• 25414c272e974192cafba60ccb07575c841b26f7e4da5d89e853f4bf75db5add

[duanyytop]

I suggest this file should be moved to rgbpp-sdk/btc and examples can reuse it

[ShookLyngs]

Maybe we should, but a concern is we may not handle P2TR well, because it can be complicated.

[ShookLyngs]

After reviewing the current codebase of the packages/examples, I think this is not a good timing to do this. Examples and tests have different needs for the feature, and it's a big change to refactor them all.

[Flouse]

• The L1 fees should be paid with the L1 RGBPP outputs because the fee rate is low

Have you tested the case where the BTC transaction requires additional inputs to pay tx fee?
@ShookLyngs @Dawn-githup

[Dawn-githup]

• The L1 fees should be paid with the L1 RGBPP outputs because the fee rate is low

Have you tested the case where the BTC transaction requires additional inputs to pay tx fee? @ShookLyngs @Dawn-githup

When the fee rate is higher, utxo will be collected from the from address to pay the fee.

[Flouse]

Discussion or TODO

• Update apps/service in a separate PR? @ShookLyngs
  feat(rgbpp-sdk-service): support generate_rgbpp_transfer_all_txs API #278

• Update https://github.com/ckb-cell/rgbpp-sdk-python @duanyytop

• Prepare integration tests with apps/service and ckb-cell/rgbpp-sdk-python @Dawn-githup

  1. Collect rgbpp-assets from a BTC address containing only one rgbpp-asset bound BTC UTXO
  2. Collect rgbpp-assets from a BTC address with multiple rgbpp-asset bound BTC UTXOs
  3. Collect rgbpp-assets from multi BTC addresses with single UTXO
  4. Collect rgbpp-assets from multi BTC addresses with multiple UTXOs each
  5. Collect rgbpp-assets from multi BTC addresses with more than 40 UTXOs in total
  6. Test edge cases
     a. addresses with no assets
     b. a BTC UTXO is bound to multi type_scripts
     • 2 xUDT
     • xUDT + DOB

• Record all the tested transactions @Dawn-githup

[ShookLyngs]

@duanyytop and I had a few discussions about the PR:

1. The .env file for the rgbpp lib is redundant, as all tests in the rgbpp lib are mocked. Can it be removed?
2. Should we keep the rgbpp lib as simple as possible, instead of adding a lot of utilities to it?
3. Developers may need an example for the transfer-all feature when coding.

My thoughts:

The .env file for the rgbpp lib is redundant, as all tests in the rgbpp lib are mocked. Can it be removed?

The btc/ckb lib contain some methods that are not mockable, meaning that when calling the buildRgbppTransferAllTxs API, actual network requests must be sent. So, while the .env file can be removed, we still need to provide a default environment so the tests can run as expected. I'm not sure if it's worth it.

I think @duanyytop is concerned about redundant test cases, as there are too many "same pieces of code" in the examples and integration tests. If we add more tests to the rgbpp lib alone, that would increase redundancy.

Personally, I believe the unit tests for the rgbpp library are different from the examples and integration tests because the unit tests allow more room for unexpected cases. However, writing tests for the buildRgbppTransferAllTxs API is challenging and requires a lot of preparation. Maybe @Dawn-github can write integration tests for the feature, and then we can remove the mocked tests from the rgbpp lib, making the .env file unnecessary.

Should we keep the rgbpp lib as simple as possible, instead of adding a lot of utilities to it?

Agreed, so I moved most of the utilities from the rgbpp lib to the btc/ckb libs at c492cf3.

Developers may need an example for the transfer-all feature when writing.

Yes, but it would be hard to write a set of examples just to prepare the assets. If we provide only one example for users who already have many assets, it would be much easier. We may add such example in examples/rgbpp/xudt/btc-transfer-all/1-btc-transfer-all.ts.

[Dawn-githup]

Regarding the transfer-all example, we are currently facing an issue: if we use this file to create a BTC account and sign transactions, with createBtcAccount it won’t support mixed-type addresses when using .env.

• For example, if we write it as "A wants to transfer all of their xudt1 to B," then the fee and change can go to A, and there's no need for multiple accounts. Would such simple support be sufficient for the example?

@Flouse @ShookLyngs

[ShookLyngs]

Regarding the transfer-all example, we are currently facing an issue: if we use this file to create a BTC account and sign transactions, with createBtcAccount it won’t support mixed-type addresses when using .env.

I think it depends on how complicated the examples need to be. If we're writing a simple example that transfers all XUDT1 from A to B, then a single account is enough. However, if we're writing an example that transfers all XUDT1 from [A, B] to C, then we'll need at least 2 accounts for signing.

It's best to draft a TODO list of the examples first. cc @Flouse @Dawn-githup

[Dawn-githup]

It's best to draft a TODO list of the examples first. cc @Flouse @Dawn-githup

• This is a simple example using a single account transfer-all

10f0457

[Flouse]

• This is a simple example using a single account transfer-all

10f0457

ok, please add an introduction to https://github.com/ckb-cell/rgbpp-sdk/blob/develop/examples/rgbpp/README.md to explain the use case of this example later.