feat(gui): transaction history for bitcoin wallet, transaction details (fee and txid, splits for bitcoin), fully-featured send dialog for bitcoin, bitcoin withdrawal confirmation dialog, more addresses button

[nabijaczleweli]

Ref: #744, pt. 1

Started with this one, more 2 come

a.mp4

[binarybaron]

I like it! It'd be cool if we could label transactions (e.g swap refund, swap lock). Not sure if bdk has support for labels.

[binarybaron]

It'd also be cool to be able to inspect the transaction to see the input and outputs, although that might be a bit much... and can also be done in a follow up PR.

[nabijaczleweli]

bdk_wallet doesn't have descriptions, we'd have to have store a (txid -> String) map ourselves.

As for splits: I'll see what I can draw from the data we get.

[nabijaczleweli]

Details -> txid+fee+splits:

a.mp4

(Please don't make me style this, I'm hopeless at React design.)

Splits are only shown if we have them (i.e. not for Monero), but then the Details show the fee which was previously available-but-hidden.

[nabijaczleweli]

Now also #744, pt. 3 (fully-featured send dialog):

aa.mp4

[binarybaron]

Now also #744, pt. 3 (fully-featured send dialog):

aa.mp4

Very cool. Love it.

We also need a confirmation dialog for the Bitcoin wallet. It's just what people expect. Most wallets display an explicit confirmation before publishing a transaction.

[binarybaron]

Also how is this possible? I supposodly sent 0.004 BTC and then received 0.002 BTC twice. Now my balance is zero. The directions may be inverted?

[binarybaron]

@rafael-xmr You can also try this out and see if you find any issues by testing it by hand and by looking over the code.

[nabijaczleweli]

The directions are definitely correct, but since these net to 0 (which is your wallet state as well) and from the times I'm guessing they were part of the same block? The sort order is confirmations (i.e. block height, as a proxy for confirmation time, but maybe there's more precision there?), then txid to force stability. Do you have txids to inspect this v/v the blockchain state? Does this get better if you in wallet.rs change

        history.sort_unstable_by(|ti1, ti2| {
            ti1.confirmations
                .cmp(&ti2.confirmations)
                .then_with(|| ti1.tx_hash.cmp(&ti2.tx_hash))
        });

to

        history.sort_unstable_by(|ti1, ti2| {
            ti1.timestamp
                .cmp(&ti2.timestamp).reverse()
                .then_with(|| ti1.tx_hash.cmp(&ti2.tx_hash))
        });

?

[binarybaron]

The directions are definitely correct, but since these net to 0 (which is your wallet state as well) and from the times I'm guessing they were part of the same block? The sort order is confirmations (i.e. block height, as a proxy for confirmation time, but maybe there's more precision there?), then txid to force stability. Do you have txids to inspect this v/v the blockchain state? Does this get better if you in wallet.rs change

        history.sort_unstable_by(|ti1, ti2| {

            ti1.confirmations

                .cmp(&ti2.confirmations)

                .then_with(|| ti1.tx_hash.cmp(&ti2.tx_hash))

        });

to

        history.sort_unstable_by(|ti1, ti2| {

            ti1.timestamp

                .cmp(&ti2.timestamp).reverse()

                .then_with(|| ti1.tx_hash.cmp(&ti2.tx_hash))

        });

?

Yes that must be it. Good catch. I'll try out those code snippets. Detecting that one of the transactions spends the output created in the same block and then ordering based on the graph is probably non-trivial and overkill.

We can sort by the balance delta of the transaction such that the "incoming" transactions within a block are displayed before the "outgoing" ones.

We get this pattern of "spending a UTXO in the same block as it was created" every time we make a swap and I found it a bit confusing so it may also be confusing to others.

I doubt that I deposited 0.004 BTC and then spent exactly 0.002 BTC for two swaps... one of them must be change. I'll have to export the wallet and look at the actual UTXOs in Sparrow.

[nabijaczleweli]

Now also #744, pt. 4:

a.mp4

[nabijaczleweli]

#744, pt. 2:

[nabijaczleweli]

I was gonna suggest partitioning incoming txes before outgoing txes, if they happen within the same block, since that would alleviate this and be computationally free (unlike a partial(?) topo sort like I think you implied in your original)... and I see that in your edit you came to the same conclusion.

I emulated your setup thusly:

        history = vec![
            TransactionInfo {
                fee: Amount::ZERO,
                amount: Amount::from_btc(0.004).unwrap(),
                confirmations: 100,
                tx_hash: "c".to_string(),
                direction: TransactionDirection::Out,
                timestamp: 0,
                splits: TransactionSplits {
                    inputs: vec![],
                    outputs: vec![],
                },
            },
            TransactionInfo {
                fee: Amount::ZERO,
                amount: Amount::from_btc(0.002).unwrap(),
                confirmations: 100,
                tx_hash: "b".to_string(),
                direction: TransactionDirection::In,
                timestamp: 0,
                splits: TransactionSplits {
                    inputs: vec![],
                    outputs: vec![],
                },
            },
            TransactionInfo {
                fee: Amount::ZERO,
                amount: Amount::from_btc(0.002).unwrap(),
                confirmations: 100,
                tx_hash: "a".to_string(),
                direction: TransactionDirection::In,
                timestamp: 0,
                splits: TransactionSplits {
                    inputs: vec![],
                    outputs: vec![],
                },
            },
        ];

and I saw what you did:

and partitioning by direction fixed it: