<kevino:tchncs.de> x.com/sebp888/status/2101510193091932161

<kevino:tchncs.de> can someone answer this ?

<kevino:tchncs.de> i am sure its been already addressed earlier but i don't recall exactly what was it

<kevino:tchncs.de> anything to do with adaptive block size ?

<kevino:tchncs.de> also to consider is currently bitcoin has lot of transactions with non-finanical data on the chain , often referred as "spam". But monero network doesn't support them op-return or witness data so there is less incentive to create spam transactions.

<bobsacmanto:matrix.org> reddit.com/r/AIDiscussion/comments/…rmgptcowormgpt4comwormgpt4net_legit has anyone use this wormgpt service?

<rbrunner7> "can someone answer this ?" Why, and answer how? A quick calculation showed me that the growth of 1.7 GB per day is probably in the right ballpark. Such a growth may be ok in a few years, thanks to technological progress, but if the number of transactions exploded to BTC levels overnight, the network would run into serious problems.

<ofrnxmr> 1.7gb for full nodes, probably closer to 600-800 mb for pruned

<ofrnxmr> Avg about 700 tx per block, and 2 mb blocks

<yokoama:matrix.org> @ofrnxmr: with fcpm++ ?

<ofrnxmr:xmr.mx> multiply by 3

<yokoama:matrix.org> @ofrnxmr:xmr.mx: Will be fun to sync wallets/nodes

<ofrnxmr:xmr.mx> syncing wallets isnt that bad

<syntheticbird> @ofrnxmr:xmr.mx: pov you live in a first world country

<elongated:matrix.org> @ofrnxmr:xmr.mx: How much data would be consumed to sync one month of blockchain ? Post fcmp++ if we have 600/700 txs per block

<ofrnxmr:xmr.mx> i have some... trusted sync mode that reduces data do a few bytes for blocks where you dont own anything

<ofrnxmr:xmr.mx> so about 6gb for the full chain today, about 1/10th of the data and sync time

<yokoama:matrix.org> @ofrnxmr:xmr.mx: few bytes per block ?

<ofrnxmr:xmr.mx> yea

<yokoama:matrix.org> @ofrnxmr:xmr.mx: So you need to run your own node, or can use any trusted* node like cake ?

<yokoama:matrix.org> no privacy issue ? or is it like lws

<kevino:tchncs.de> @yokoama:matrix.org: i think the how the communicates with each other doesn't change after fcmp++

<ofrnxmr:xmr.mx> @yokoama:matrix.org: one you trust with some info about your txs

<kevino:tchncs.de> node*

<ofrnxmr:xmr.mx> its not as bad as lws, but it requests data from node about specific transactions that match your view keys

<ofrnxmr:xmr.mx> there is another alternative, which is about 13gb of local storage, and drops the resolve part

<yokoama:matrix.org> @ofrnxmr:xmr.mx: doesnt lws do the same ?

<ofrnxmr:xmr.mx> but the biggest saving resolves matchess

<kevino:tchncs.de> so if you were trusting a remote node before this upgrade then probably you can still trust them

<ofrnxmr:xmr.mx> no, lws scans the whole chain and knows definitively what txs are your, and their amounts

<yokoama:matrix.org> @ofrnxmr:xmr.mx: yah the so called trusted node can save your view key and scan the entire chain

<ofrnxmr:xmr.mx> my scandata thing resolves all txs that match your view tags, with have a false positive in 1/256 txs

<ofrnxmr:xmr.mx> scandata doesnt share view keys

<ofrnxmr:xmr.mx> it uses view tags

<yokoama:matrix.org> @ofrnxmr:xmr.mx: so you send view tags & get related txs from node per block and only check them

<ofrnxmr:xmr.mx> currently we downlaod all data, and only scan the data that matches out view tags. scandata only downloads view tags, and resolves the txs that match the tag

<ofrnxmr:xmr.mx> of which only real matches and 1/256 false positives are scanned. so even during a period with no activity, you will resolve 1/256 txs that dont match and are discarded locally. the node doesnt know which txs that you scan are yours, but it can learn which view tag groups you are resolving

<yokoama:matrix.org> is this being implemented ? or just your idea

<ofrnxmr:xmr.mx> its implemented locally, and if it does go upstream it wont happen til fcmp

<kevino:tchncs.de> @yokoama:matrix.org: i think this will be part of the light wallet . But regular wallets would still have your view keys locally

<ofrnxmr:xmr.mx> there are numerous ways to tackle the issue, such as using a shared local cache

<ofrnxmr:xmr.mx> reduces sync to about a minute

<kevino:tchncs.de> @yokoama:matrix.org: its part of carrot i think

<ofrnxmr:xmr.mx> for the full scan of general fund, or for my spam wallet on fcmp

<ofrnxmr:xmr.mx> the resolve method is better for people using tor, or mobile, since storing 15gb is a big ask

<ofrnxmr:xmr.mx> but for desktop users, the stored cache is better, since wallets can reuse it

<ofrnxmr:xmr.mx> and this is even better for lws, which current has to sync a ton of data from a local node. can be reduces to 15gb and a few mins for a full sync, instead of upwards of an hour for each new wallet connected

<ofrnxmr:xmr.mx> using gpus to run off the same cache does a sync in about 10 seconds

<ofrnxmr:xmr.mx> so the tldr is that, wallet sync time is current ineffient due to old designs, not due to limitations

<ofrnxmr:xmr.mx> bandwidth is likewise much higher than necessary

<ofrnxmr:xmr.mx> node sync is another story. there are plenty of places it can be sped up, but its not so easy

<ofrnxmr:xmr.mx> wallet sync is a relatively simple matter, if you dont mind changing the design

<ofrnxmr:xmr.mx> like, syncing over tor is slow ah because you have to download a LOT of data, and it all uses a single circuit, sqeuential downloads. parallelize downloads, use separate circuits, and you 2+x the speed

<ofrnxmr:xmr.mx> reduce the bandwidth 9x and you effectively reduce the sync time on tor by the same

<elongated:matrix.org> When ccs to research on wallet usability

<wolixoriginal23:matrix.org> ask why is so slow to sync wallets on for

<ofrnxmr:xmr.mx> @elongated:matrix.org: wwwwhat for, its being done for "free" by numerous people

<ofrnxmr:xmr.mx> @wolixoriginal23:matrix.org: i just answered this. bandwidth

<ofrnxmr:xmr.mx> wallet download a ton of data that it doesnt need

<ofrnxmr:xmr.mx> dont download the data = turn an 8 hour sync into 56mins

<ofrnxmr:xmr.mx> 45*

<ofrnxmr:xmr.mx> download the data using multiple circuits and turn a 45min sync into 30

<ofrnxmr:xmr.mx> why no pr? because there are 500 different ways to attack the problem. dont need to change the design 10x, just need PoC for each of them, so they can be evaluated and compared

<ofrnxmr:xmr.mx> example, the downloading of cache and a flag to tell the wallet to check the local cache before syncing from the node is relatively simple and could probably land without much opposition

<ofrnxmr:xmr.mx> but adding a change that needs to stitch together connections due ti multiple circuits / parallel downloads, needs more scrutiny so that its not silently building corrupt wallets

<ofrnxmr:xmr.mx> multi-node sync likewise. if you are connected to a swarm of nodes and one of them is sending bad data, that can cause issues. scandata being someone of a privacy reduction in exchange for a 5-10x increase in sync speeds when using a trusted node, also requires the node that you are connected to supporting the new rpc endpoint [... too long, see mrelay.p2pool.observer/e/39rjwawLVGREQmRt ]

<ofrnxmr:xmr.mx> on fcmp alone, i think i got something like a 30x speedup with a couple bug fixes + scandata

<ofrnxmr:xmr.mx> bug fixes were 6x alone, and scandata another 5x on top of that

<ofrnxmr:xmr.mx> bug fixes like 50 loc altogether, possibly land with the next stressnet

<wolixoriginal23:matrix.org> @ofrnxmr:xmr.mx: because I using cake wallet means once be downloaded automatically sync to node

<ofrnxmr:xmr.mx> if/when any of these changes are formally proposed, cake will inherit them

<wolixoriginal23:matrix.org> because cake wallet is partnered with monero to make monero wallet on android

<yokoama:matrix.org> i dont see any improvements on wallet sync, last one was view tags > <@ofrnxmr:xmr.mx> wwwwhat for, its being done for "free" by numerous people

<ofrnxmr:xmr.mx> didnt you read the last 50 messages i sent

<yokoama:matrix.org> ai can code poc, dont need real dev time > <@ofrnxmr:xmr.mx> why no pr? because there are 500 different ways to attack the problem. dont need to change the design 10x, just need PoC for each of them, so they can be evaluated and compared

<yokoama:matrix.org> if poc looks good then devs can code it properly

<ofrnxmr:xmr.mx> sech1 has a gpu scanner that does it in 8 seconds, plowsof has cache and multinode that cuts time to ~1min (cache) and cuts download in half, and i have scandata + cache that also hits the 1min mark and reduces bandwidth by 90%

<yokoama:matrix.org> @ofrnxmr:xmr.mx: going through it

<ofrnxmr:xmr.mx> all of us have PoCs tested and in use locally

<ofrnxmr:xmr.mx> but none are production ready, and all have drawbacks or design choices that need addressing. such as gpu times are only on a modern gpu with preprocessed data, scandata requires new rpc endpoints and is built against fcmp repos, and multinode sync exposes you to more potentially malicious nodes

<ofrnxmr:xmr.mx> the common denominator for remote note enhancements currently seems to be a 15gb local cache that can be reused across wallets

<ofrnxmr:xmr.mx> whether that is feasible is not yet known. as in, is this something people would use for a wallet? 15 gb is a lot of data for an android app if you arent using multiple wallets, and it only helps when syncing an old/restored wallet or catchup sync on a 2nds+ wallet. the first wallet still needs to download a lot of data

<ofrnxmr:xmr.mx> modifying the download is a major change that isnt likely to get consensus quickly.

<isaac_newton:matrix.org> I know a skitzo rant when I see one

<ofrnxmr:xmr.mx> shut up setvin

<ofrnxmr:xmr.mx> cant even spell the word

less than 8 seconds actually: p2pool.io/u/4e4c135dd01424b7/image.png

<wolixoriginal23:matrix.org> guys iam have question what wallet is best for monero

<isaac_newton:matrix.org> @wolixoriginal23:matrix.org: I like feather or just the main GUI wallet built from source

<wolixoriginal23:matrix.org> @isaac_newton:matrix.org: for android

<isaac_newton:matrix.org> Cake is popular for Android but I never use mobile wallets

<isaac_newton:matrix.org> @wolixoriginal23:matrix.org: You can get termux and build the cli from source

<isaac_newton:matrix.org> What happened to all the "early adopters?" 😇

<pw:xmr.mx> @wolixoriginal23:matrix.org: you just mentioned one in a previous coment.

<pw:xmr.mx> take it to #monero-offtopic:monero.social too

<isaac_newton:matrix.org> Monero wallets are off topic?

<cookingnan:matrix.org> x.com/umbraXMR

<pw:xmr.mx> 50/50 :D

<nestle5432:matrix.org> I'm looking for some good written resources on poisoned output/EAE attacks, I wasn't really able to understand the Breaking Monero video on it. Does anyone have any that explain using an actual blockchain explorer?

<nestle5432:matrix.org> plowsof: Thank you.

<isaac_newton:matrix.org> 🙄

how good is monero

<jpk68:matrix.org> It's the greatest thing ever

it's life itself

<isaac_newton:matrix.org> 🚪

<alisterswine:matrix.org> СВИНЬИ

<ravfx:xmr.mx> narf: It's the only one

<ravfx:xmr.mx> There is no second best

<isaac_newton:matrix.org> @ravfx:xmr.mx: There was a first best

<ravfx:xmr.mx> @isaac_newton:matrix.org: That would be Monero

<isaac_newton:matrix.org> Two knocks and a handshake at the barber shop

<ravfx:xmr.mx> iced version is comming soon™

<ravfx:xmr.mx> 72M hamsters burned so far

<ravfx:xmr.mx> s/hamsters/tokens/g

<jpk68:matrix.org> What made you choose Iced over egui? Just curious :)

<ravfx:xmr.mx> @jpk68:matrix.org: Iced leverage opengl/VK better afaik. I did not do very very very deep research but basic search told me to use that one. Plus you seam to know your rust options very good and it's the first one you mentionned

<jpk68:matrix.org> I wouldn't take my word for it, but sounds good :D

<ravfx:xmr.mx> Well, so far your recommendation has been very good

<jpk68:matrix.org> Though egui is more minimal, if that's what you're going for

<ravfx:xmr.mx> @jpk68:matrix.org: I want something that work good and is small. It's why I initially tought about x11rb. But Iced and egui seam to both be very small. And I am fine with iced, it does use video accel on all platform and won't require any extra shit.

<ravfx:xmr.mx> The goal is to make it small yes and also I don't want to be bothered with the distribution (I just want the binary to just work on everything I try it to) so both option are good but I have the feeling Iced might be faster

<ravfx:xmr.mx> So I assume that if it work fine with Iced, I will just have to install a 10 years old Debian and build it on that (for the Linux release)