--- Log opened Wed Apr 24 00:00:38 2024
01:18 < setavenger> Josie: FYI noticed that the numbers in the appendix regarding cut-through are still the old numbers.
02:05 < josie> setavenger: thanks for the reminder! still need to update the appendix 
03:08 -!- cygnet3 [~cygnet3@185.65.134.187] has joined #silentpayments
03:56 -!- cygnet3_ [~cygnet3@86-95-185-145.fixed.kpn.net] has joined #silentpayments
03:58 -!- cygnet3 [~cygnet3@185.65.134.187] has quit [Ping timeout: 255 seconds]
04:01 -!- cygnet3_ [~cygnet3@86-95-185-145.fixed.kpn.net] has quit [Client Quit]
14:26 < setavenger> josie: I came across a bit of a scanning issue today during testing. My indexing server prunes spent UTXOs from the UTXO set and does not provide them for scanning. Now I had a transaction spending to myself and to my change address. Receiving those together works just fine for the first scan. Now after spending the first UTXO and rescaning, I was not able to find the second output. The reason was that both had the same 
14:26 < setavenger> scan key but different Bm. The change output had been using `k = 1` and was never reached during scanning, as the first output, which had been pruned, was not found for `k = 0`.
14:26 < setavenger> Is this an implementation issue or expected behaviour?
14:26 < setavenger> I guess the learning for me here is that indexing servers probably have to keep all UTXOs for a transaction until ALL UTXOs for a given tx are spent. This also means that any implementation is forced to check all labels which were generated/handed out. For the reason that any of those labels could have been `k = 0`. Is this correct? This would mean that instead of only always checking for the change label `m=0` an 
14:26 < setavenger> implementation should look for all labels `m = [1..n]`. 
14:26 < setavenger> Just something I noticed and didn't seem super obvious from the Bip and the discussions I've read up to now.
--- Log closed Thu Apr 25 00:00:37 2024