Model more transaction history details

[Restioson]

Addresses #872 by modelling more history details for different kinds of events (transactions, trades, fees, etc).

I don't think this PR should address the Figma mock beyond adding all the info that it has to the display and that should rather be done in a followup, but happy to change this if desired.

• Model on-chain payment data
  • Confirmations
  • Fee
    • Check if the fee reported is correct
• Model lightning payment data
  • [ ] From node I do not believe this to be possible without an explicit proof-of-payment protocol: https://bitcoin.stackexchange.com/a/85555
  • Invoice description
  • Payment preimage
  • Invoice itself
  • Show expiry time
  • Show expired payments
    • Test
  • Handle failed payments (fixes Show failed transactions in transaction history #1140)
    • Test
• JIT fee - blocked on Show JIT channel fee in wallet history #1103
• Order matching fee
  • Order ID

Questions:

• What should we do about unpaid invoices in the database?

Related: #1103

[Restioson]

With ec9b7de, I insert the invoice into the payments table upon creation. This is required to know the description once the payment has been claimed. However, it also leads to the payment just sticking around in the DB if it's unpaid. I'm not sure what we want to happen here from a UX perspective if the user creates an invoice and it isn't paid (expiry date & periodic sweep to remove? notify user?).

[Restioson]

This is more-or-less ready, aside from the above comment

[holzeis]

With ec9b7de, I insert the invoice into the payments table upon creation. This is required to know the description once the payment has been claimed. However, it also leads to the payment just sticking around in the DB if it's unpaid. I'm not sure what we want to happen here from a UX perspective if the user creates an invoice and it isn't paid (expiry date & periodic sweep to remove? notify user?).

I would remove it once it has expired. I think our invoices are already created with an expiry.

[luckysori]

LGTM, except for the preimage. I would leave that out completely :D

Can we get some screenshots too? 👀

[Restioson]

Can we get some screenshots too? 👀

I can make some, although it isn't pretty as this is just the modeling side of things and not the display

[luckysori]

Can we get some screenshots too? 👀

I can make some, although it isn't pretty as this is just the modeling side of things and not the display

Fair enough, we can look at the screenshots once that's nicer.

[Restioson]

I would remove it once it has expired. I think our invoices are already created with an expiry.

See these lines in native::ln_dlc::create_invoice:

10101/mobile/native/src/ln_dlc/mod.rs

Lines 578 to 584 in e30aa48

	node.inner.create_interceptable_invoice(
	amount_sats,
	0,
	"Fund your 10101 wallet".to_string(),
	final_route_hint_hop,
	)
	})

How should we interpret this? Apparently lightning (the crate) adds two hours (gleaned by reading the code):

https://github.com/lightningdevkit/rust-lightning/blob/3dffe54258a374d15571d4ec72f5faa02477b770/lightning/src/ln/inbound_payment.rs#L237-L243

I'm not sure if we can rely on the +2 hours, but maybe we just should?

Also, there is a default expiry time: (1 hour).

[Restioson]

@luckysori some screenshots! Missing on chain because it's a pain 😆 but I can take one if we need. It requires restarting the app to show up.

[Restioson]

I would remove it once it has expired. I think our invoices are already created with an expiry.

Actually, I'm not so sure of this. I think an expired invoice is semantically a failed payment (or maybe we can add a new HTLCStatus for this called expired), or something similar.

User stories for this (proposed) feature:

• As a wallet user,
  • I want to check on the history of invoices I've sent
  • so I know if the transfer was paid, expired, or failed
• As a 10101 sysadmin,
  • I want to check if any invoices from the coordinator are expiring unexpectedly
  • so I can monitor the health of the coordinator

If the user creates an invoice, sends it off, and it isn't paid, they should be able to go back and see that it wasn't paid instead of silently disappearing, imo.

[Restioson]

I've pushed 720fc36 to implement the above feature, but it's untested as I still need to wait the hour for it to expire (I could make one expire on purpose but since it's Friday, I may as well wait till Monday 😉)

Similarly, 3892963 fixes #1140, but I'm not sure how to force a failed transaction.

[Restioson]

Example of a failed payment

[Restioson]

I think this is ready, pending review. That is to say, I am happy with it now.

[Restioson]

Are we happy with this? If so, I can resolve conflicts for merge

[luckysori]

LGTM, thank you!

[bonomat]

I guess we can make it look nice in a follow-up PR :) Thank you Cael.

[Restioson]

I guess we can make it look nice in a follow-up PR :) Thank you Cael.

That's the idea - I wanted to stick to the backend side (hence 'model more') here and implement just the minimum amount of frontend to test it. I figured that the looking nice could be up to more debate.

I'll rebase this soon for merge

[Restioson]

Ah, maybe I should have a crack at displaying the fees for lightning transactions

[klochowicz]

@Restioson could we try to merge this soon to avoid the need for rebasing? we can always keep improving in a follow-up, and these changes can be useful for others :)

[Restioson]

@Restioson could we try to merge this soon to avoid the need for rebasing? we can always keep improving in a follow-up, and these changes can be useful for others :)

Sure, I'll do that today!