--- Log opened Mon Aug 15 00:00:51 2022
01:52 < darosior> I think we should only return the txids that were actually CPFPed, otherwise what's the point of returning the txids at all? They would always be the same as the ones in the request parameters.
01:52 < darosior> An alternative is to just return the CPFP transaction id.
01:57 < Zeeshan> They won't be same as parameter because I'm passing transactions to `cpfp_package` if `should_cpfp` gives a green light on the txid
01:57 < Zeeshan> If we can to return the ones that are CPFPed, we'll have to modify `cpfp_package`'s return value
02:07 < darosior> I think you necessarily need to modify the return value of cpfp_package(). At the moment it assumes it's only called by the poller, and on error it'll log as error and return Ok(()). You can't do that for an RPC call. So here is what i think you should do:
02:07 < darosior> 1. Make `cpfp_package` part of `bitcoind/utils` instead of `bitcoind/poller`
02:07 < darosior> 2. Make `cpfp_package` always return an error when it encounters one, and log in the poller's caller on error (`maybe_cpfp_txs()`).
02:07 < darosior> 3. Make `cpfp_package` return the txids of the transactions that were CPFP'd. The caller in the poller can log them
02:07 < darosior> 4. Use that in your `cpfp()` function for manual CPFP. But here instead of logging on error or success, you actually propagate the result
02:08 < Zeeshan> What is the general idea for putting things in `bitcoind/poller`? does it have to be strictly only used by the poller or is it more arbitrary than that? asking out of curiosity
02:09 < Zeeshan> I see, so we are pushing the error handling out of `cpfp_package` and propogating down the chain and then handlng them differently in the `poller` and `cpfp()`
02:10 < darosior> Yes, the poller.rs module should only contain logic for the poller
02:10 < darosior> Yes
02:11 < Zeeshan> So since `cpfp_package` is being used in a place apart from the poller it is being pushed out, correct?
02:46 < darosior> Yes
02:46 < darosior> And since its behaviour is not specific to the poller anymore, it's generalized
07:18 < darosior> edouard[m]: for `listcoins`, should we have all past and present coins or only current unspent ones?
07:21 < edouard[m]> If we reuse the same logic for listhistory, the gui will need listcoins to get the amount moved from the spend inputs outpoints
07:21 < edouard[m]> mmmh maybe not
07:23 < edouard[m]> in fact gethistory has all the information it needs
07:24 < edouard[m]> I think it can give only the current ones for now, we can add filters later
14:44 -!- darosior [~darosior@194.36.189.246] has quit [Read error: Connection reset by peer]
14:48 -!- darosior [~darosior@194.36.189.246] has joined #revault
--- Log closed Tue Aug 16 00:00:52 2022