00:22:36 Why is it that wallets always seem to synchronize about 600 blocks at a time? Y600 and not 1,000 or 100 or 350. 00:48:19 @shortwavesurfer2009: its not 600, ive seen it do example 1000 and 350 00:48:57 @ofrnxmr:xmr.mx: What determines what it does? 00:48:59 Probably is some amount of data, not a set number of blocks 00:49:04 @shortwavesurfer2009: Not sure 00:49:34 @ofrnxmr:xmr.mx: For example, I just saw it do a chunk of 726. 00:53:41 And the next chunk only dropped by 203. 00:55:51 And then 630 00:56:02 So you can never really tell exactly how much it's going to drop. 01:02:24 Data doesn't seem to match up either. One chunk took like 220 megabytes, and another chunk took like 140 megabytes. 01:04:45 And then a chunk took 70 megabytes. 01:21:10 There are a few limits it'll take the lowest on, number of txs (20000), number of blocks (1000) and megabytes (100 MB). > <@shortwavesurfer2009> Why is it that wallets always seem to synchronize about 600 blocks at a time? Y600 and not 1,000 or 100 or 350. 01:22:35 @boog900: How does it determine which one to use? Can it be specified manually? 01:23:15 it stops at the first one hit, and no 01:24:09 @boog900: Damn. 01:24:31 why do you want to change it? 01:26:19 @boog900: Because I lost my fiber connection for a 36 hour period and was wanting to sink my wallet and was unsure if it was actually synchronizing or not. And now that I look at it again, I think it was, but I was never able to tell that it was actually working. I was on 256kbps (32KB/s) and my wallet just kept saying starting synchronization instead of reporting a block count. 01:26:47 I was hoping I could set it to like 10 megabytes to test. 01:27:20 Because I was just getting no feedback otherwise. 01:29:19 Even on a connection that's slow, 10 megabytes still downloads fast enough to be useful for a feedback mechanism to know that it's actually working. 01:33:45 Yeah the limit is done daemon side too so you can't even compile your own wallet. 01:34:47 the wallet just sends a list of known hashes and the daemon responds with blocks following those hashes until it hits one of those limits. 01:35:13 Yeah, 256kbps is a common data throttle limit, and so I was trying to work out a way to make sure I could use Monero on that kind of a connection, because it is possible for it to occur. 01:36:29 What determines how often the data gets written to disk? Because I've seen several times where I would be synchronizing my wallet and only get a couple of chunks and close the wallet and then reopen it and have to synchronize the same chunks again. 01:41:14 I'm not sure on that, my focus is on the daemon side with cuprate :) 01:41:57 Ah, okay. I was trying to figure out if some sort of low bandwidth mode could be done, but apparently the answer to that is no. 01:43:44 Is there some sort of trade-off if those limits were to be changed? Like, what if they were to be halved? Or, what if they were to be doubled? 01:43:46 I think it would only be practical with a light wallet. 01:44:32 Yeah, and I was really trying to avoid a light wallet because of the security implications before FCMP. 01:48:26 @shortwavesurfer2009: decreasing limits means more communication to sync a given set of blocks, increase is more data needing to be sent in a single response. 01:48:26 The lower the limits the slower your sync will be due to needing to send more requests. 01:50:07 @boog900: Ah, thanks. This has been very helpful. Not what I was hoping to hear, but helpful nonetheless. 01:50:36 Depends on the wallet implementation > <@shortwavesurfer2009> What determines how often the data gets written to disk? Because I've seen several times where I would be synchronizing my wallet and only get a couple of chunks and close the wallet and then reopen it and have to synchronize the same chunks again. 01:50:38 Some dont "store" the wallet at all until sync completes 01:52:21 @ofrnxmr: Is this somehow configurable? 01:52:41 https://github.com/monero-project/monero/issues/9332 01:53:48 @shortwavesurfer2009: No 01:54:51 @ofrnxmr: Damn. Since the synchronization part wasn't configurable, if that part was at least configurable, then you could tell it to save every single chunk on a low bandwidth connection. But I guess not. 01:54:52 Looks like a light wallet really is the only possible option, but the security implications behind that are sad. 01:55:57 I was really, really trying to avoid the possibility of having to use a light wallet. 01:55:58 There are "no" security implications 01:56:29 I guess I should say privacy implications since the light wallet server sees your transactions. 01:56:46 you can run your own light wallet server 01:57:15 Sure, if you have internet, but if you're in a situation like I was the other day, where my internet was down, then you can't run your own light wallet server. 01:58:10 lws doesnt use more data than syncing a wallet normally 01:58:52 Well, if you figure out a way to synchronize a Monero node and use a light wallet server with no internet, let me know. 01:59:18 if you figure out a way to use crypto w/o internet ;) 02:00:04 I had no home internet the other day. My node would not sync because I had no internet. I could not have used my own light wallet server because I had no internet. I was completely reliant on somebody else's infrastructure, such as Cape Wallet, etc. 02:00:25 I thought your node was syncing? (1 block at a time) 02:01:46 Yeah, sure. When I turned on my hotspot on my phone and plugged the ethernet cable into my Wi-Fi router, 02:02:08 I was just doing that to see if it could be done. 02:03:17 My phone's 256 KBPS hotspot became my home internet by using a USB Type C to Ethernet adapter and plugging the ethernet cable into the WAN port of the router. 02:35:06 It's turtles all the way down. 13:22:22 https://github.com/MAGICGrants/skylight-wallet/releases 13:23:06 thoughts about this light wallet, peeps 13:50:04 Light wallets are for women 13:54:28 I'm sure you could talk your mother into helping you use it, but in the long run it'd be better for you to face your fears and try to use it. Maybe for just a few seconds the first time, just to see it's not that unsurmountable. 13:59:21 xmr_guyy: "Unlike most Monero wallets, Skylight Wallet offloads wallet scanning from your device to a light-wallet server. This server uses your private view key to detect related transactions, and it only sends you those transactions. This process is efficient, but it grants the server operator knowledge of your transactions. [... too long, see https://mrelay.p2pool.observer/e/i-qo9vIKWmVQVkpQ ] 14:01:36 big thanks, br-m 14:03:12 br-m is the bridge, the posters name is after that 14:04:24 @seen bable fish 16:26:17 Thanks for the clarification! > <@kiersten5821:matrix.org> unlike what the other guy said the risk is also basically 0. they are not freezing random people's stablecoins. there are a total of like a few hundred addresss on the blacklist and they're all added manually, those blacklisting keys are kept quite safe and it's not just some random add to db or api call 21:41:56 Hello, what do you use with monero wallet cli to have fallback nodes? haproxy ? socat? nginx? wouldn't it be interested to have such feature as parameter of monero-wallet-cli command? 23:53:55 im running a IPv6 only Node but the sync p2p is still with IPv4