--- Log opened Tue Mar 12 00:00:25 2024
02:32 < josie> setavenger: "utxos resent to a used address" meaning if someone sends coins to the address outside of the silent payments protocol?
02:33 < josie> its not necessarily true that rescanning wont find those coins: silent payments is a way to generate a scriptPubKey. once generated , you can query the utxo set as you would normally, i.e. checking if that scriptPubKey has unspent coins. thats not specific to silent payments, so i dont see why it wouldnt find all coins sent to that address?
02:36 < josie> regarding light clients, my expectation is that light clients wouldnt support full chain rescanning (i.e. recovering their full tx history). light clients should support recovering your unspent balance (utxo set scanning)
02:37 < josie> which is where the cut through becomes really useful, because now the light client scanning work is dependent on how many unspent taproot utxos exist, not dependent on how long since the clients last scan 
02:40 < josie> one idea i had but never pursued was a index that is more of a modified utxo set: the index tracks unspent taproot outputs and includes the necessary tweak data along with the utxo (33 byte sp_tweak + outpoint + scriptpubkey + amount), so the index updates with every new block, removing spent outputs and adding new outputs, and then allows clients to query block ranges to check for newly
02:40 < josie> created utxos to see if they belong to the client
06:47 < RubenSomsen> josie: I believe the scenario is one where Bob sends coins to Alice, Alice then spends them, Bob sends coins again to the same address (imo protocol violating behavior), Alice initiates a rescan with cut-through and won't detect the coins. Imo this is expected and fine. We could certainly consider building a special recovery tool that detects a bunch of protocol deviating behavior, but I see no reason to support it by default.
07:53 < josie> RubenSomsen: ah i see the point. i also agree that we cant make guarantees and shouldn't be concerned with trying to handle edge cases where people are not following the protocol 
07:54 < josie> (by not be concerned, i mean these should be more general wallet concerns and not specific to silent payments logic)
09:18 < setavenger> RubenSomsen: exactly that scenario is what I meant. I do agree that this isn
09:21 < setavenger> *this isn't necessarily in scope for the protocol specification. Hence I believe it would be nice to have some sort of aggregation among light client devs. To think and solve these edge cases and concerns.
09:32 < setavenger> Josie: I've built such an indexing server as you are describing, just needs some performance optimisations. The components are separate and not one concatenated value, but the idea is the same. I'm also constructing taproot-only filters. Then the process is as follows. Get tweaks, create scriptpubkeys, if match on filter, request simplified utxos and find the matched utxo. The index server also implements cut-through. I 
09:32 < setavenger> guess that's what you were hinting at in the BIP appendix
23:09 -!- dergoegge [sid453889@2a03:5180:f:2::6:ed01] has quit [Ping timeout: 268 seconds]
23:09 -!- dergoegge_ [sid453889@id-453889.lymington.irccloud.com] has joined #silentpayments
23:09 -!- dergoegge_ is now known as dergoegge
--- Log closed Wed Mar 13 00:00:26 2024