--- Log opened Wed Jun 29 00:00:06 2022
03:39 -!- belcher [~belcher@user/belcher] has joined #revault
03:56 < darosior> edouard[m]: so i understand why it helps is the coordinator gives you the deposit outpoints. But i'm not sure why you can't cache by deposit outpoint at the moment?
06:10 < edouard[m]> Because then in order for an other outpoint to retrieve the spend from the cache, I have to check the unvault output to the inputs of each spend in the cache
06:11 < edouard[m]> If the coordinator gives me directly the deposit outpoints the tx is spending, then it is easier to find in the cache the spend tx for a given outpoint 
06:38 < edouard[m]> https://github.com/revault/practical-revault/pull/128
06:42 < darosior> I must be missing something. What's wrong with something like this: https://github.com/darosior/miradord/tree/ed_demo_cache_spend
06:43 < darosior> (apart from duplicating the Spends, but this is solvable without modifying the protocol)
06:49 < edouard[m]> With your solution, the coordinator will do a request for every vault.
06:51 < edouard[m]> The correct loop is: check cache for a outpoint if not exists: retrieve the spent, populate the cache with the spend and ALL its deposit_outpoints
06:53 < darosior> It's not incorrect per se 😅
06:54 < darosior> Just you can optimize it further, true
06:55 < edouard[m]> do you mean that the db_vault list may contains duplicate ? https://github.com/revault/miradord/commit/c718dc59dda2e6aed312448377d437d83ee88b1b#diff-9fab9a5920b5f04b0adfffd0612cda1a6de603651bd1eb06f9530c15bd95e192R370
06:56 < edouard[m]> Because I thought the cache would be to not having to retrieve two times the spend for two different vaults with the same spend tx
07:00 < darosior> Oh right i'm dumb
07:00 < darosior> See, i was missing something :)
07:02 < edouard[m]> Ah, more contextual  information were missing certainly
07:04 < darosior> Yes, my bad
07:04 < edouard[m]> I can reuse the cache you gave as example, but in order to retrieve the spend for another vault I would need to loop across each spend tx inputs and match it against the vault unvault output.
07:04 < darosior> I need to jump on a call soon, i'll get back afterward, but you probably right
07:05 < edouard[m]> Meanwhile, I am making a PR for coordinatord
08:14 < darosior> wait
08:16 < edouard[m]> ok
08:16 < darosior> i don't think we should prioritize this. Just go with a TODO and open an issue to discuss how to fix it. A protocol modification isn't the only way to approach this (for instance we could register the Unvault txid in DB). I think we should think twice before rushing into modifying the protocol, and the optimization isn't really necessary at the
08:16 < darosior> moment. Let's finish the feature and optimize later on
08:17 < darosior> (ofc i agree this needs fixing before it gets any real use)
08:17 < edouard[m]> Ok I understand
11:32 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 260 seconds]
11:45 -!- belcher [~belcher@user/belcher] has joined #revault
11:53 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 246 seconds]
12:07 -!- belcher [~belcher@user/belcher] has joined #revault
13:44 -!- belcher [~belcher@user/belcher] has quit [Quit: Leaving]
--- Log closed Thu Jun 30 00:00:07 2022