Feature request: history via api

[theborakompanioni]

Would it be possible to serve the output of wallet-tool.py <wallet> history via the api?
Do you think this is a useful feature that should be implemented?

e.g. (simplified example)

GET /api/v1/wallet/{walletname}/history

{
  "history": [{
    "tx_no": 0,
    "timestamp": 123456789,
    "type": "deposit",
    "amount": "0.00000001",
    "balance_change": "+0.00000001",
    "coinjoin_n": null,
    "total_fees": null,
    "utxo_count": 1,
    "mixdepth_from": null,
    "mixdepth_to": 0
  }, {
    "tx_no": 1,
    "timestamp": 123456789,
    "type": "cj intsweep",
    "amount": "0.00000001",
    "balance_change": "-0.00000001",
    "coinjoin_n": 2,
    "total_fees": "0.00000001",
    "utxo_count": 1,
    "mixdepth_from": 0,
    "mixdepth_to": 1
  },
 [...]
 ]
}

Related issue in Jam: joinmarket-webui/jam#515

[kristapsk]

Concept ACK on idea, but note that this currently might be slow, especially on old wallets, I mean minutes. Not sure how well Jam will handle that. Related - #1349.

[theborakompanioni]

Pump, due to "popular demand".

A pair of offset/count or page/size params for pagination would also be quite helpful.
Would that make the operation finish more quickly? Assuming majority of the users are interested in the most recent transactions.

[kristapsk]

Would that make the operation finish more quickly?

Not sure how much. Still need to request all transactions from Bitcoin Core. This was my motivation why I worked on bitcoin/bitcoin#19443.

[kristapsk]

Somewhat related - #420. Qt GUI does not use full history functionality, it just saves list for itself. It works well if you only use single wallet and only use Qt GUI, but not in other cases.

[kristapsk]

But way forward I think would be to just expose history functionality we already have via API and then look from there how usable it is, what improvements we can make on top of that. And that would mean no pagination options for now, you always get full history.

[theborakompanioni]

But way forward I think would be to just expose history functionality we already have via API and then look from there how usable it is, what improvements we can make on top of that. And that would mean no pagination options for now, you always get full history.

If that is acceptable for you, then yes, that would be awesome. Should pagination be supported in the future, I think this can easily be added in a backward compatible way. 💪

[kristapsk]

Would that make the operation finish more quickly?

Not sure how much. Still need to request all transactions from Bitcoin Core. This was my motivation why I worked on bitcoin/bitcoin#19443.

Actually paging might help, wallet_fetch_history() calls gettransaction RPC not only for JM transaction itself, but also for all input transactions, to figure out which inputs are ours.

Btw, #1625 was great optimization, make it run few times faster for old wallets with a lots of tx history.