Supporting chained-transactions

[Keith-CY]

This issue comes from #56 (comment)

---

【Preview sending transaction pop-ups】This will contain basic information about the build transaction and visual charts to help users understand the upcoming transaction submission and customize its settings in subsequent iterations.

1. The transaction preview pop-up appears after the user clicks send on the send page.
2. Preview information includes transaction hash, transaction information, transaction topology and operation area.
   • Transaction hash：Display full transaction hash and support replication
   • Transaction information:Display amount, fee, size and cyclesdata,no interaction.
   • Transaction topology：Includes transaction inputs and outputs,need to display the type and amount and support floating layers to display the full address.
   • Operation area:Confirmation and submission of transactions.
3. Users need to be alerted when a transaction has been chained-up or removed.

[Keith-CY]

1. I found there's only a send button on the window, which means it's mandatory to submit the transaction into the chained-transactions. IMO, the chained-transactions is an optional optimization because it may fail or take time. So the send button should be a menu of send directly and send in queue etc.
2. What does the intermediate dialog(click next) do between send and confirm
3. The chained-transactions can be viewed in a dialog with an open button next to each other. Is there a topology graph of the chained-transactions to be displayed?

[homura]

I suggest we can rename the title to "Supporting advanced transaction", because the chained-transaction should be an implicit feature that just allows a client to use an uncommitted cell, and they don't need to chain the transactions manually. After a (chained) transaction has committed, it would appear in the transaction list with a Pending status

But I think this draft design is still a good point to start for "advanced transaction". When a user enters the advanced mode, they can

• preview the transaction structure consists of
  • (resolved) input cells
  • output cells
  • estimated cycles
  • estimated fee
  • size
  • hash
• replace input cells
  • force to choose cells with data or type
• adjust output cells
  • capacity of each one
  • construct cell manually, e.g. create a sUDT cell with 0 amount, pay fee by recipient, dived into smaller parts

[yanguoyu]

This feature will start after #218 because cell management will affect generate transactions.

1. Add a parameter usePendingCell to control whether use pending cells when generating a transaction.

[Danie0918]

1. Chained transactions - use pending cells to build transactions when enabled, submit transactions separately when not enabled
2. Result popup - Removed. This is because there are currently results in the history and chained transactions cannot be predicted.

[yanguoyu]

I will create 2 PRs to complete this task.

• Support uses sent cells to send CKB. feat: Support use sent cell when send CKB nervosnetwork/neuron#2963
• Show the transaction detail that uses sent cells Feat: view chain transaction detail nervosnetwork/neuron#2986

[silySuper]

Only when the balance is insufficient can I build a transaction through the cell ？If not，when build a transaction through the cell what is the difference between balance is insufficient and balance is sufficient ?@Danie0918

[Danie0918]

Only when the balance is insufficient can I build a transaction through the cell ？If not，when build a transaction through the cell what is the difference between balance is insufficient and balance is sufficient ?@Danie0918

I didn't quite get it . Chained transactions have nothing to do with balance, chained transaction mean lower fees and faster transaction speed.

[Keith-CY]

Only when the balance is insufficient can I build a transaction through the cell ？If not，when build a transaction through the cell what is the difference between balance is insufficient and balance is sufficient ?@Danie0918

Chained transaction has a special usage that it can boost a pending transaction, named Child pay for parent(https://bitcoinops.org/en/topics/cpfp/#:~:text=Child%20Pays%20For%20Parent%20(CPFP)%20is%20a%20fee%20bumping%20technique,both%20transactions%20in%20a%20block.)

Briefly speaking, if a transaction_a was submitted with a lower fee, it will be de-prioritized. To fix the transaction fee, another transaction_b, which includes the outputs of transaction_a could be submitted with a higher fee, then the average fee of each transaction will be leveled up. Once the average fee is higher than the medium fee, these two transactions will be mined together.