--- Log opened Wed May 11 00:00:20 2022
00:05 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #revault
01:11 < darosior> So edouard[m] for what screen are you using the change index from #386?
01:11 < edouard[m]> The vault history view
01:12 < darosior> Hmmm. Isn't there confusing to have optimistic/imperfect calculations there?
01:12 < edouard[m]> and maybe the history event view if we add a tab showing the onchain transactions
01:13 < darosior> Like what if the Spend transaction has 2 outputs paying to a deposit address
01:13 < darosior> Or what if the Spend transaction has the change output not paying to the same derivation path (which would be a good practice)?
01:14 < darosior> Are we telling them "you expensed the entire value of the transaction"?
01:15 < edouard[m]> For the moment, we display the transactions without any information about the outputs
01:16 < edouard[m]> We need this information if we want to be consistent with the others views
01:16 < darosior> Ok, cool, so we treat it as a failure
01:16 < darosior> Hmm what about cases where you can't know it's a failure? Like the first i mentioned
01:24 < edouard[m]> By failure you mean, the incapacity to detect the (maybe second) change output  or the change with a different derivation path. Then the user will see the funds not labelled as change
01:24 < edouard[m]> He will maybe check that a vault was created with the spend txid and output index
01:24 < edouard[m]> It is annoying but less bad than the other way.
01:27 < edouard[m]> -> He will maybe check that a vault was created with the spend txid and output index
01:27 < edouard[m]> maybe I can add this as a second check
01:27 < edouard[m]> by searching in the db all vaults with the spend txid as deposit txid
01:28 < edouard[m]> It will be racy because of the poller interval, but we can use it as a second check
01:29 < darosior> I think that checking if a txid is part of the deposits is a more robust way of detecting change, yeah. But it doesn't work when you haven't broadcast the tx yet (like for `listspendtxs`)
01:35 < edouard[m]> Yes, but with the psbt format we could use the output bip32_derivaition field and the keysources to detect all the change outputs, if and only if the change outputs are added by our software  
01:37 < edouard[m]> An external software may only add the output address without information of bip32_derivaiton
01:41 < darosior> That sounds pretty brittle. It's what HWs do to detect change but it's because they don't have any other context. If it's for history purposes i'm not sure we should try to do a boutique detection of change..
01:44 < darosior> I'll comment on the PR with more structured arguments, but i think it's a bit misguided :/
02:13 < edouard[m]> I read your comment, do you think we have the same problem with cpfp outputs ?
03:00 < darosior> For the Unvault less so because we can assume that pre-signed transactions are fixed by the protocol (you could have a getter in revault_tx for the unvault cpfp). For the Spend.. Yes i think so
03:01 < darosior> And it's even harder because then you can't really know which one is the CPFP output. Maybe by using the amount but meh
03:06 < edouard[m]> okok, guess I will extract the unit test for getonchaintransactions to put it in another PR, all is not lost :)
03:09 < darosior> Yep! :)
03:10  * darosior watches CI repeatedly fails with what was my ultimate optimization
03:23 < darosior> This failure is especially awkward https://cirrus-ci.com/task/5686309766299648?logs=test
03:55 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
05:21 < darosior> edouard[m]: i'm tempted to use the dummy coordinator for aquarium, what do you think?
05:21 < darosior> Removes the need for docker/Postgre
05:21 < darosior> But on the other hand, it's not testing "for real" anymore
05:22 < darosior> Can do like i did in #402, and keep the possibility to use both
05:22 < darosior> Guess i'll do that
05:26 < edouard[m]> yes good idea
05:58 < darosior> Hmmm. The dummy coordinator means all the data is transient though
05:58 < darosior> But we don't support to restart an existing aquarium anyways
07:53 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #revault
08:14 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
08:43 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #revault
10:15 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
17:39 -!- cryptoquick [~cryptoqui@8.46.89.33] has quit [Quit: Ping timeout (120 seconds)]
17:39 -!- cryptoquick [~cryptoqui@8.46.89.33] has joined #revault
18:05 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #revault
18:21 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 240 seconds]
18:34 -!- belcher [~belcher@user/belcher] has joined #revault
19:01 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
19:03 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #revault
20:14 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 276 seconds]
20:26 -!- belcher [~belcher@user/belcher] has joined #revault
21:05 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
22:15 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #revault
22:29 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
22:56 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #revault
23:33 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
23:33 -!- evanlinjin_ [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #revault
23:45 -!- evanlinjin_ [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
--- Log closed Thu May 12 00:00:21 2022