elsirion
elsirion
> Maybe we should introduce an additional derivation element that would mean "generation". I think daily backups are an easier solution, then you only have to search for notes since...
Oh lol, you already merged it
Maybe not completely remove it, just change the log level or something. It helped with debugging the slow LN payments.
Related to c554ff89500b590cb80e4d919b5e6789ae95a825 that fixes overly fast polling and still needs to be upstreamed afaik.
Where should that information live? Easiest solution seems to be saving a timestamp for all epochs and have an index `contract -> [(epoch, transaction)]` and then look up the time...
I think client side filtering is reasonable since it doesn't put any additional index burdens on the federation and invoices should generally only be given to a single person. If...
What are the target versions ob `bitcoin` and `rand` for this to work?
This should be resolved if #796 is fixed right? Maybe we can just fork `bitvec` for now and repce it workspace-wide in the hope of upstreaming fixs to its dependency...
> Is there any downside from using public-key derivation-supporting scheme here? Is it doably? There are two keys per e-cash token: * **Spend key**: secret key needed to spend the...
A log file would be rather uncommon for a client/one-shot CLI tool imo. > While we could reduce the log level to debug for mint_client::api, the logs of jsonrpsee would...