--- Log opened Thu Sep 15 00:00:20 2022
02:03 < darosior> edouard[m]: did you start tackling signing devices integration? What did you start with? Specter or Ledger
02:50 < darosior> I've finally opened https://github.com/revault/minisafe/pull/27. Will review gethistory now
07:27 < edouard[m]> I am gonna start with Specter
07:27 < edouard[m]> https://github.com/revault/revault-gui/blob/master/hwi/src/specter.rs
07:58 < darosior> Ok!
08:14 < darosior> edouard[m]: did you get the issue with assuming the spend transactions are always confirmed?
08:19 < edouard[m]> Ok I read your answers
08:20 < edouard[m]> We are currently using spent_coins to update coins with the spend_txid
08:20 < edouard[m]> And we are using it to update the blockheight in coins table
08:21 < edouard[m]> I just modified it to update the blocktime in coins table
08:23 < edouard[m]> So I suggest we can do a second round of update in the bitcoin poller that will check for coins that have a spent_txid and no blockheight or blocktime and will update it after checking if tx is confirmed
08:29 < darosior> If it's no confirmed then we just received it. What about using the current time instead of the blocktime for the 'spend_at'?
08:33 < edouard[m]> If we want to handle multisig later, blocktime is the only time that is not subjective to the node the user is using
08:34 < darosior> Hmm so you think all users should have the same result for a `gethistory <X> <Y>`?
08:35 < edouard[m]> yes, it was what we wanted for revault
08:35 < edouard[m]> But if we change this assumption for minisafe, we still have the FIXME to do for the blockheight
08:36 < darosior> I think it made sense when we wanted to have accounting features and all for revaultd around this call but it looks like it grew to be bigger in scope that. We could have an accounting-specific call that only considers confirmed transactions (and in any ways accounting is about the past where it's very likely everything is confirmed already)
08:37 < darosior> And keep gethistory, i don't know, something else 😅
08:37 < darosior> It's already something else
08:37 < edouard[m]> I disagree
08:37 < darosior> Yeah for the block height of the spending transaction? Well it could be optional couldn't it?
08:37 < edouard[m]> for changing the rpc command, 
08:38 < edouard[m]> We need to change our methods
08:38 < edouard[m]> and create some that handle "confirmed" transactions
08:39 < darosior> What do you mean? I don't want to change the RPC commands, just to keep gethistory like that (but to not assume spending transactions are always confirmed)
08:44 < edouard[m]> Ok so we update the coins table the coins that are "spending" with a spent_txid that is at risk to move right ?
08:45 < edouard[m]> We can as you said populate the spent_at with the tx `received_at`
08:46 < edouard[m]> but maybe it would be nice to do a second update in the poller that check if the spend tx is confirmed
08:46 < edouard[m]> it will change the txid in case of rbf for example
08:46 < edouard[m]> spent_txid i mean
08:48 < darosior> Yes, right, we definitely need to monitor for the spend confirmation
08:50 < edouard[m]> and in this case it will update the spent_at with the correct blocktime.
08:50 < edouard[m]> In fact we can represent in database a coin that is "spending" by the fact it has spent_txid  populated and spent_at null
08:50 < edouard[m]> and a "spent" coin that has both column populated
08:53 < darosior> Yes! Will need to think about that when we take care of reorgs but it should be trivial
08:53 < darosior> Cool
08:55 < edouard[m]> So in my PR I am adding a new check in bitcoin poller that retrieve "spending" coins, ask bitcoind for tx confirmation and update spent_txid and blocktime if it changed/confirmed
08:56 < edouard[m]> and I am removing the change made for the method `spent_coins`
08:56 < edouard[m]> (that i can rename as spending_coins mayvbe)
09:01 < darosior> Yes, this monitoring for spend confirmation can also have its own PR. And you could base the gethistory PR on top of it
09:02 < darosior> Yes, spending_coins sounds like a better name
09:02 < edouard[m]> ok
--- Log closed Fri Sep 16 00:00:21 2022