ThomasV
ThomasV
probably something went wrong when you ran configure
sorry for the conflicts. two issues: - do not call bitcoind on each request; better cache the result, as I did for relayfee - do not mix tabs and spaces,...
it is not possible to parallelize this process, if that's what you mean. I agree it would be useful to have builds from independent sources.
maybe related: #7940 (seems to be caused by `utxo_list` not updated when it should)
this is because they run it from a usb stick
It would be misleading to return `tx_hashes` if the request was paid using lightning. (because the address will be recycled in another request) Currently this PR does not handle that.
if a request R1 is paid with lightning, its address will be reused in another payment request R2. if R2 is paid onchain, you will see the tx hash paying...
Lightning requests have an on-chain fallback address. we need to recycle these addresses because otherwise we would soon hit the gap limit.
This seems to affect only imported wallets. Maybe `utxo_list._spend_list` is not reset after an address is deleted? We rely on `utxo_list.update()` to reset that list, but there is no guarantee...
> @ecdsa should we maybe hack the order of the sigs in the aggregated signature file so that yours comes first? how would that help?