--- Log opened Wed Mar 13 00:00:26 2024
02:27 -!- b10c [~quassel@user/b10c] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
02:29 -!- b10c [~quassel@static.33.106.217.95.clients.your-server.de] has joined #silentpayments
02:29 -!- b10c [~quassel@user/b10c] has changed host
02:29 -!- b10c [~quassel@user/b10c] has quit [Client Quit]
02:30 < josie> setavenger: very cool! in this model, it sounds like the client is requesting a range of "simplified utxos" so that the server doesn't learn exactly which utxo the client is interested in?
02:33 -!- b10c [~quassel@user/b10c] has joined #silentpayments
04:08 < setavenger> Josie: yes, exactly. At the moment it's on a per block basis, all eligible "simplified utxos" will be sent out for the client to find a match. I guess that's a good trade-off between privacy and bandwidth. Depending on tests this can also be changed without trouble. But I'm honestly still a bit worried when it comes to computation of scriptPubKeys on a small device. The EC computations are pretty intensive.
04:21 < josie> setavenger: im also curious to see benchmarks for a small device. one nice property of cut-through is the amount of work a small device needs to do increases only with the size of the UTXO set (not with time since last scan). im curious to see how much work this ends up being for a client that scans every couple of days
04:22 < josie> do you have a repo for your index? 
04:30 < setavenger> Josie: I already did a couple of test runs with an early version of a react native app on iPhone13 Pro (would say that this is already on the more "beefy" end of mobile devices around). That was on signet and it was rather long (>10min minimum IIRC). This can probably still be optimised because it was more of an MVP, but there's only so much you can do with regards to the EC computations on mobile.
04:31 < setavenger> Josie: Repo: https://github.com/setavenger/BlindBit-Backend
06:13 < josie> setavenger: nice, awesome that you have some numbers! with >10 mins, this is scanning the whole signet chain? or scanning the UTXO set (i.e. taking advantage of cut-through)
06:34 < setavenger> Josie: Utilising Cut-through and a couple thousand blocks. I think it was around 166000 -> 172000. But I'm not hundred percent sure those were the numbers. The concept hasn't really changed since then. Was just able to stabilise and improve syncing performance on the indexing server.
06:35 < setavenger> I believe there's still some room for improvement on the mobile side. Maybe fetching more tweaks in a batch could help, I was going per block, so on signet there is a more networking relative to response size. Although on mainnet that won't necessarily be as applicable.
06:36 < setavenger> I'm currently indexing from taproot height and after that I can create a first baseline for mainnet over a couple blocks.
08:32 < josie> setavenger: awesome! excited to see what the numbers are. im not sure how you are doing the cryptography on the phone, but im curious what sort of speed up (if any) you would see if using libsecp
08:33 < josie> im mentioning this because one of my current goals is to get the silent payments logic in a libsecp module, to take advantage of libsecps optimizations 
09:39 < setavenger> I'm using elliptic a JS ECC implementation, the problem is it's JS and it's react native creating even more constraints. If performance is too bad I will look into bindings or a similar ways to get libsecp into the app.
09:46 < setavenger> Josie: But I think there's a pretty high chance that I'll have to drop the JS implementation. The index server seems pretty stable now. So I'm putting that aside and focusing on mobile in the next days.
--- Log closed Thu Mar 14 00:00:27 2024