--- Log opened Wed Mar 20 00:00:32 2024
01:28 < setavenger> My assumption was correct, average processing time dropped by ~29% to 497µs. This would mean that 85min -> ~61min for pure tweak processing.
01:28 < setavenger> But I noticed a little Blunder. I missed that I also have to precompute the pubkeys for labels (at least the change label). This might not be relevant on a regular scan as a wallet could already remember change outputs when creating/sending the tx to save some trouble. 
01:28 < setavenger> For sake of completeness I'll add that as well.
01:40 < setavenger> I do have one question though normally one would find an output for a label by doing `Compute label = output - Pk` so I could do `Pk + label = output` and use that for the filter, correct? Where I'm not sure is how does the computation work if I have to negate the output. Is it simply `-output - Pk = label` => so I can filter with `Pk-label = output`? 
01:40 < setavenger> I guess it's simple arithmetics but I'm not sure whether there are any twists with EC computations.
02:15 < josie> setavenger: thanks for sharing the numbers! ~500μs for a phone is a helpful number to know
02:18 < josie> regarding labels, you can scan for them in two ways: say i have 5 labels, i create Pk and then check Pk + l1, Pk + l2, Pk + l3, etc.
02:20 < josie> this is fine for a small number of labels, but as the number of labels grows, its better to precompute the labels and check to see if (output - Pk) matches one of your labels
02:22 < josie> in the context of a phone wallet (and scanning using filters), it seems there isnt a way to do (output - Pk) since you only have a filter for the block, so youd have to use the first method for labels. imo, i think a phone wallet should always scan for the change label but not support labels otherwise (or only support a limited number, maybe no more than 5?). this way, the first method of
02:22 < josie> scanning works fine
02:22 < josie> it also shouldnt add much time since an ECC addition / subtraction is almost trivial compared to an ECC mult
02:39 -!- cygnet3 [~cygnet3@185.65.134.177] has joined #silentpayments
02:39 < cygnet3> hello!
03:02 < setavenger> Josie: yeah I was not going to use labels (except a change label) for the v1. Does the math check out on finding the potentially negated output to find it via filters?
03:14 < setavenger> cygnet3: Hi, you're behind DonationWallet, right? Is that a light client as well?
03:15 < cygnet3> yes we use a bip158 backend! (nakamoto)
03:20 < josie> setavenger: its been awhile since ive thought about this, but the math checks out. iirc, you might not need to check the negated output if you are using the Pk + label method for scanning (vs the output - pk method), but i need to double check this
03:23 < setavenger> cygnet3: interesting approach. So the wallet connects directly to the p2p network?
03:24 < setavenger> Josie: Thanks, I'll run the numbers on only Pk+label first then.
03:25 < cygnet3> yep, although actually for the tweak data we are currently using a fork of electrum to serve it
03:28 < cygnet3> setavenger: but we only use electrum for getting the tweak data, not any address scanning stuff, for that we use the compact block filters
03:34 < setavenger> cygnet3: that's cool. I'm using a custom indexing server for the tweak data and some peripherals to make it easier for my light client. 
03:36 < setavenger> Do you already have some benchmarks? I started writing down some notes and processes in a repo, including benchmarks for index sizes etc. No way near complete. Would also help to compare the indexes if you have it available. https://github.com/setavenger/BIP0352-light-client-specification
03:51 < cygnet3> sadly no benchmarks, we haven't gone too deeply into the performance of the indexing, and i haven't run it on mainnet myself yet. we're currently focusing on the wallet itself, we'll return back to looking at the indexer when the wallet's further along
04:04 < setavenger> ok, feel free to add interesting nuggets to the repo through a PR. I think we can turn that repo into a valuable resource for other light client developers. I also want to publish the API for the indexing server for easy integration with other wallets. 
04:04 < setavenger> But considering you have done indexing in Electrum, I might even prefer that solution over a custom backend depending on the peripherals it provides for the light client.
04:09 < josie> setavenger, cygnet3: documenting light client learnings on a repo is a great idea. long term, i think it will eventually make sense to have a sp-lightclient-protocol (similar to the electrumx protocol). this way, independent indexers can be built and still be interoperable. today, it feels a bit premature for that, but documenting findings in a single place is a great first step towards
04:09 < josie> that 
04:45 -!- stickies-v_ [sid544753@id-544753.uxbridge.irccloud.com] has joined #silentpayments
04:53 -!- Netsplit *.net <-> *.split quits: stickies-v
04:53 -!- stickies-v_ is now known as stickies-v
11:02 -!- cygnet3 [~cygnet3@185.65.134.177] has quit [Quit: Leaving]
--- Log closed Thu Mar 21 00:00:33 2024