Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wallet Tx Details lost Output/s #26

Closed
johanneshahn opened this issue Apr 12, 2022 · 4 comments · Fixed by #30
Closed

Wallet Tx Details lost Output/s #26

johanneshahn opened this issue Apr 12, 2022 · 4 comments · Fixed by #30

Comments

@johanneshahn
Copy link
Member

The Wallet DB lost the outputs in its details and via API calls.

If user receive a transaction and watch the details or calls this tx details from api he will get a list from the outputs for this transaction.
receive_detail

If user then creates a new send transaction and use the output he previously receveived from the receive transaction,
then the list from the outputs is empty.
receive_detail2

Details of users new send transaction with the output he receives previously (new tx id is now 73)
receveive_detail3

The Details for the outputs is not shown, because the tx id of the output is changed if users creates a new transaction.
The new tx id can not be assigned to older transactions. A history is missing

@yelloweyesage
Copy link

Same here

@MarcioMacedoBA
Copy link
Contributor

MarcioMacedoBA commented May 12, 2022

Describe the bug

Some details of the wallet output are lost after transactions.

To reproduce

This issue can be easily reproduced on usernet as follows:

  • Start the server: epic --usernet;
  • Create three empty wallets (here named A, B, C): epic-wallet --usernet init
  • Mine some coins for wallet A: epic-wallet --usernet listen
  • Send C coins from wallet A to wallet B (via send command): epic-wallet --usernet send -m file -d 'temp.txt' -s smallest C
  • Receive C coins from wallet B (via receive command): epic-wallet --usernet receive -i 'temp.txt'
  • Finalize the transaction from wallet A (via finalize command); epic-wallet --usernet finalize -i 'temp.txt'.response
  • Mine 10 blocks to validate the transaction (you can put wallet A on listen mode to allow the mining): epic-wallet --usernet listen
  • Print the taxes and outputs of wallet B to confirm the receipt of the C coins (txs and outputs commands):
    • epic-wallet --usernet txs
    • epic-wallet --usernet outputs
  • Send C coins from wallet B to wallet C (via send command): epic-wallet --usernet send -m file -d "temp.txt" -s smallest <C-fee>
  • Receive C coins from wallet C (via receive command): epic-wallet --usernet receive -i 'temp.txt'
  • Finalize the transaction from wallet B (via finalize command); epic-wallet --usernet finalize -i 'temp.txt'.response
  • Print the taxes and outputs of wallet B to confirm the sending of the C coins (txs and outputs commands);
    • txs prints the correct information and assignes the send command to a new transaction id;
    • -s outputs contains the sending of the C coins, but pointing to the id of the most recent transaction (the old transaction id is lost);

@MarcioMacedoBA
Copy link
Contributor

MarcioMacedoBA commented May 12, 2022

@johanneshahn I am in doubt about what should be the expected behaviour in this case. Should the outputs command print the list of transaction ids (one per outputs line, for instance) that are associated with a given output, and the user could then trace, or better investigate their relation through the use of the txs command?

@MarcioMacedoBA
Copy link
Contributor

Just to report that I saw from the Grin documentation and that the source codes that Grin wallets have the same behavior as Epic wallets with respect to the outputs command, only storing the last transaction id for each output.

@MarcioMacedoBA MarcioMacedoBA linked a pull request May 26, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants