Magickbase / neuron-public-issues

Neuron Issues
6 stars 3 forks source link

Supporting chained-transactions #217

Open Keith-CY opened 1 year ago

Keith-CY commented 1 year ago

This issue comes from https://github.com/Magickbase/neuron-public-issues/issues/56#issuecomment-1626710809


【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.

Image

Keith-CY commented 1 year ago
  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 commented 1 year ago

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

yanguoyu commented 1 year ago

This feature will start after https://github.com/Magickbase/neuron-public-issues/issues/218 because cell management will affect generate transactions.

  1. Add a parameter usePendingCell to control whether use pending cells when generating a transaction.
Danie0918 commented 9 months ago
  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 commented 9 months ago

I will create 2 PRs to complete this task.

silySuper commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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.