<fr33_yourself> I have a couple of questions regarding the Proof of Worked Enabled Relay (PoWER). What is the current verification time of a 128 input transaction currently? And what it is it after FCMP? I think I saw 3 ms or 3 secs? Also, after FCMP, what would be the maximum number of 128 input transactions that could fit in a block? Why is [... too long, see mrelay.p2pool.observer/e/6_Cns_QKa3FJZUlZ ]

<ofrnxmr:xmr.mx> Theres a chart of verification times somewhere

<fr33_yourself> But the problem post FCMP is the verification time of those high-input transactions right? Like right now the network couldn't be DOS'd right?

<ofrnxmr:xmr.mx> It takes much longer to generate them than it takes to verify them

<ofrnxmr:xmr.mx> So sure, you could potentially try to create garbage 128 input txs, but thats part of what power if for (iirc), it would drop/ban the peer for sending you a bad tx

<fr33_yourself> And that won't be the case after FCMP right? It flips that relationship. Sorry I've been away for a while so I'm trying to get caught up on recent developments.

<ofrnxmr:xmr.mx> if valid, the inputs take virtually the same amount to verify in bulk as theyndk separarely

<ofrnxmr:xmr.mx> So sending sixteen 8in txs takes ~same verify time as one 128in

<ofrnxmr:xmr.mx> But the 8ins use more bandwidth and storage

<fr33_yourself> Do we have any estimates as to the maximum number of 2 in 2 output transactions that could fit in an average FCMP block after the upgrade? What are the scaling limits looking like after FCMP? And what is the current bandwidth limit? Isn't it like 32MB? That was a topic of conversation last time I was in here around December

<ofrnxmr:xmr.mx> 7.5kb / 1mb

<ofrnxmr:xmr.mx> Er no, damn whats the new penalty free block aiE again?

<fr33_yourself> @ofrnxmr:xmr.mx: If FCMP blocks are 1mb and 2 in and 2 out are 7.5kb, then that's like 130 transactions per block or 93,600 per day

<kiersten5821:matrix.org> it's getting raised from the current 300 kb?

<fr33_yourself> Maybe he's just talking hypothetically like after the dynamic block algo kicked in

<ofrnxmr:xmr.mx> 7.5/625kb

<fr33_yourself> What will be the primary challenges for miners to stay in sync after FCMP? The verification of time of the transactions in blocks, the sheer size of blocks or???

<fr33_yourself> What makes FCMP so much heavier and slower than the current version?

<ofrnxmr:xmr.mx> No

<ofrnxmr:xmr.mx> Monero uses fluffy blocks. When a block is mined, it doesnt send the whole block (with txs)

<ofrnxmr:xmr.mx> It only sends txs if the recipienr node is missing them

<fr33_yourself> This would be about 80tx per block and 57,600 per day. > <@ofrnxmr:xmr.mx> 7.5/625kb

<ofrnxmr:xmr.mx> So txs are verified as they arrive on your mode, not all at once when the block is mined

<ofrnxmr:xmr.mx> @fr33_yourself: We do about 40 right now @ 25-40k per day

<fr33_yourself> @ofrnxmr:xmr.mx: Yes, I'm just trying to think through how far we can push scaling post FCMP and what exactly causes the issues with scaling. What aspect of FCMP makes it more heavier than the current setup?

<ofrnxmr:xmr.mx> We pushed blocks to 30mb without issue (after fixes)

<ofrnxmr:xmr.mx> And fcmp really made little to no difference. The issues would have been problem with rct

<ofrnxmr:xmr.mx> Verification wasnt an issue. Issue was propagation delays due to inefficient tx and block relay + other strange design decisions

<fr33_yourself> @ofrnxmr:xmr.mx: The recent point releases fix the scaling upper-bound issue that was being discussed? Or these fixes of the technical debt haven't been implemented yet.

<ofrnxmr:xmr.mx> most of the bigger performance related debt has been tackled on stressnet

<fr33_yourself> So you think the FCMP stressnet could handle 30mb blocks?

<fr33_yourself> @ofrnxmr:xmr.mx: was Ooo hardcarrying?

<ofrnxmr:xmr.mx> Still a ton more can be done (look at sync times between cuprate and monerod), but you could almoat say monerod was crippled or broken before

<ofrnxmr:xmr.mx> @fr33_yourself: No, he's been 👻 for a little while

<ofrnxmr:xmr.mx> Jberman dealt with the vast majority of the performance issues, and 0xfffc boog and berman did the tx relay v2

<ofrnxmr:xmr.mx> @fr33_yourself: Without breaking a sweat

<kiersten5821:matrix.org> so its raised to 625kb?

<fr33_yourself> What do you think the upperbound blocksize is with current technology post FCMP?

<ofrnxmr:xmr.mx> @kiersten5821:matrix.org: Penalty free zone bumped from 300kb to 625 , yea

<fr33_yourself> Upperbound meaning miners don't fall out of sync with each other and things break

<ofrnxmr:xmr.mx> @fr33_yourself: 99.9mb

<kiersten5821:matrix.org> im still a believer in not having too bloated blocks, remember the guy in support who was trying to sync a node on 256 kb/s internet

<ofrnxmr:xmr.mx> And not because od performance but because of growth and bandwidth

<ofrnxmr:xmr.mx> @kiersten5821:matrix.org: He also doesnt listen

<ofrnxmr:xmr.mx> I told him on simplex before he came here, and it took like 2 days for him tk run the node as instructed

<kiersten5821:matrix.org> my pc can only verify 2.4 block/s it will take literally 2 minutes to sync this block > <@ofrnxmr:xmr.mx> 99.9mb

<fr33_yourself> If this is true, then at 99mb blocks with 7.5kb transactions we could do about 13,000 per block or 9.36 milllion tx per day. That sounds too good to be true haha > <@ofrnxmr:xmr.mx> 99.9mb

<ofrnxmr:xmr.mx> Your nlde verifies txs as they enter the txpool

<kiersten5821:matrix.org> node not always live

<ofrnxmr:xmr.mx> Well then you wouldnt be able to catch up :P

<ofrnxmr:xmr.mx> at 30mb blocks nobody fell behind

<ofrnxmr:xmr.mx> Even 1gb ram 4core potatoes that we tested on

<kiersten5821:matrix.org> But if my node offline for a week then it will take a week to catch up...

<ofrnxmr:xmr.mx> Get a better node ❤️‍🩹

<fr33_yourself> Eventually only miners, and large services like cake, will run nodes IMO. It will eventually be too resource intensive for the run of the mill end user. And that shouldn't be an issue as the remote wallets in Monero seem to have similar security to that of SPV on Bitcoin right?

<kiersten5821:matrix.org> trust me no one will sync a node if it takes a week

<kiersten5821:matrix.org> and therefore no one will have privacy from the node operator

<kiersten5821:matrix.org> because they will use remote node

<ofrnxmr:xmr.mx> @fr33_yourself: Thats a fact of large blocks regardless. Either you pony up and run the infra or some(ne else will

<fr33_yourself> @kiersten5821:matrix.org: They can use a VPN or connect over Tor to a Tor node

<ofrnxmr:xmr.mx> The opposite is to cripple the network and have it only be used for some niche demographic

<kiersten5821:matrix.org> @ofrnxmr:xmr.mx: "everyone needs to run a node for max privacy" and "only large services and miners will run nodes because it will be super resource intensive" are not compatible

<ofrnxmr:xmr.mx> wont be able to run nodes on your 128gb sd card rasp pi forever

<fr33_yourself> @ofrnxmr:xmr.mx: I'm not criticizing it, just describing the outcome of the system. My question is more of the current remote node functionality being similar security wise to SPV right? I think it is even more secure because you request more block data. But it could be good to have a few remote nodes you alternate between if you think one of them might be feeding you false block data

<ofrnxmr:xmr.mx> Cant run your gaming computer on 64mb ram forever either

<kiersten5821:matrix.org> in the current system dont you need to download ALL the block data?

<ofrnxmr:xmr.mx> You do need to

<ofrnxmr:xmr.mx> Well, if you run a pruned node you can use --sync-pruned-blocks to skip some

<ofrnxmr:xmr.mx> But that only applies to the checkpointed section of the blockchain

<kiersten5821:matrix.org> thats even worse when you have 100 mb blocks and 1 guy connects who hasnt opened his wallet in 2 days and it will cost you 140 gb?

<fr33_yourself> @ofrnxmr:xmr.mx: If you use a remote node you only need to sync from the restore height of the wallet in question

<ofrnxmr:xmr.mx> Oh, for wallets. No, wallets downlaod pruned blocks

<ofrnxmr:xmr.mx> Much much less data than a node

<ofrnxmr:xmr.mx> I think the whole chain currently takes loke 30gb to sync from 0

<kiersten5821:matrix.org> i still dont see how running node being super expensive is compatible with everyone needs to run a node because otherwise node operator can do xyz and ruin your privacy

<ofrnxmr:xmr.mx> I dont see how everyone running a node makes any sense at all period

<kiersten5821:matrix.org> it doesn't but it still shouldn't be astronomical cost

<fr33_yourself> ofrn, how does our remote node system compare security wise to SPV in Bitcoin? Isn't it similar? And isn't Monero even a bit more secure because it queries more block data than SPV does in Bitcoin? > <@ofrnxmr:xmr.mx> Oh, for wallets. No, wallets downlaod pruned blocks

<kiersten5821:matrix.org> bitcoin spv has 0 privacy you send all addresses to the server

<kiersten5821:matrix.org> that is how electrum works

<ofrnxmr:xmr.mx> it doesnt compare

<ofrnxmr:xmr.mx> Our remote nodes are identical to local nodes

<fr33_yourself> So remote nodes in Monero are more secure against being fed bad block data right? Than most SPV wallets on Bitcoin?

<ofrnxmr:xmr.mx> No

<ofrnxmr:xmr.mx> Our wallet treat remote nodes the same way they treat local ones. The block data is fed to us and we verify that it matches cknsensus rules etc but we cant know if someone if feeding us a splintered network

<ofrnxmr:xmr.mx> You cant just use any random node you found on a dark alley and expect to be using good data

<kiersten5821:matrix.org> there are huge valid concerns with using only remote nodes (chainal linking txid and outputs to ip, input withholding attack, etc), and the response to users was run your own node, it's not right to make the nodes unrunnable unless you have crazy resources, at least it should be kept feasible on moderate consumer hardware

<ofrnxmr:xmr.mx> In bitcoin, you trust the electrum servers in most wallets OR you run your own node and have the wallet stored on the same server as the node (so cannot use someone elses remote node). Apples to apples would be saying thay your only option in bitcoin is to run a node and an lws server, or you have to trust someone elses electrum server with all of your privacy

<fr33_yourself> @ofrnxmr:xmr.mx: That was my suspicion. But this is the same as SPV. The point is that you as the end user should query multiple different nodes to see if your balance is correct and more importantly if your submitted transaction was actually included in a block and subsequently the chain. Basically this issue is resolved [... too long, see mrelay.p2pool.observer/e/gJWFtfQKQmxlQ3hQ ]

<ofrnxmr:xmr.mx> @fr33_yourself: Thats why you and your recipient shouldnt be using the same node

<kiersten5821:matrix.org> i think the block size should be capped, just like bitcoin

<ofrnxmr:xmr.mx> If everyone uses cake's node, you dont know if cake actually relayed it

<ofrnxmr:xmr.mx> @kiersten5821:matrix.org: Lmfao

<ofrnxmr:xmr.mx> Theres a coin for that: bitcoin

<fr33_yourself> Excellent point. I didn't think about that either. So really the solution is to query multiple nodes that seem to be honest and non-deceptive

<kiersten5821:matrix.org> monero should not be locking max privacy behind insane hardware requirement

<kiersten5821:matrix.org> you know there are problems with remote nodes and chainal are running them because of that

<fr33_yourself> Monero isn't very useful if it doesn't scale

<ofrnxmr:xmr.mx> Monero's block size is soft-capped. It cannot grow out of control in a short period of time, and cannot grow unless people pay for the growth over large periods of time

<ofrnxmr:xmr.mx> @kiersten5821:matrix.org: Sounds very ill-informed to me

<ofrnxmr:xmr.mx> Chainanal running nodes is the biggest joke ive ever heard

<ofrnxmr:xmr.mx> some of us know far better how to trace a monero tx than chainanals circus act

<kiersten5821:matrix.org> how, there literally is a warning in the docs somewhere about the input withholding which deletes privacy, and chainal is running nodes linking the ip to the txid

<fr33_yourself> he's actually right. They did. But you need to have some ideas about whose node you are connecting to. This is a skill and information (of good public nodes) issue, not a protocol issue.

<ofrnxmr:xmr.mx> and how many rpc nodes have chainanal ran? Like zero

<ofrnxmr:xmr.mx> Cuz theyre retarded

<kiersten5821:matrix.org> how would you even prove an rpc node is not run by chainal

<ofrnxmr:xmr.mx> And the witholding attack doesnt work if you re-submit the same tx using a diff node (the same decoys are used)

<fr33_yourself> I think they actually did catch one guy because they linked his IP that connected to a chainalysis node to an IP that had a suspicious transaction on an instant exchange.

<fr33_yourself> But once again, this isn't a protocol issue

<ofrnxmr:xmr.mx> @kiersten5821:matrix.org: Because we have researchers monitoring the netowkr?

<ofrnxmr:xmr.mx> We had bad actors running rpc nodes that cause you to lose money

<kiersten5821:matrix.org> @ofrnxmr:xmr.mx: 99% of users wont know wtf is going on though... this is catering to the most pro of the pros, also i'm pretty sure the wallet will use different decoys which is how the attack was even feasible?

<ofrnxmr:xmr.mx> The spy nlde used on chainanal leak video was... a proxy to one of OUR nodes

<ofrnxmr:xmr.mx> They didnt even run their own node

<kiersten5821:matrix.org> how do you know a random rpc url that gets listed on a website is not chainanal proxy to someone else's node > <@ofrnxmr:xmr.mx> Because we have researchers monitoring the netowkr?

<ofrnxmr:xmr.mx> @kiersten5821:matrix.org: I dont know the specifics, but the wallet caches the decoys and will reuse them

<fr33_yourself> Ofrn, how long do you think it would take for the blocksize to go to 99mb if blocks were fully and people paid enough fees starting tomorrow. Like how long would it take to jump up to that point? And you actually think a good chunk of the current Monero miners could come up with the resources to consistently handle 99mb post fcmp blocks?

<ofrnxmr:xmr.mx> The tx is already generated and just needs to be resubmit using submitrawtransaction

<kiersten5821:matrix.org> i'm pretty sure the wallet doesn't cache the decoys and requests new ones which was exactly why the attack worked because you know the ring members which didn't change are the real ones?

<ofrnxmr:xmr.mx> Featherwallet does this by default by submitting the tx to every node that configured

<kiersten5821:matrix.org> does the wallet-gui or cli do that though

<ofrnxmr:xmr.mx> Multi-submit? No

<ofrnxmr:xmr.mx> Monero-gui connecys you to random malicious nodes 🧠

<kiersten5821:matrix.org> you cannot expect normal users to know or do these though it has to be as simple as "if you run a node you get max privacy"

<ofrnxmr:xmr.mx> thats not true.

<kiersten5821:matrix.org> yeah i remember somehow someone used simple mode and then the tx had an 8 monero fee

<ofrnxmr:xmr.mx> Running youe own node does not have max privacy

<kiersten5821:matrix.org> man its crazy to say nodes will be so expensive normal users cant run them

<kiersten5821:matrix.org> well yes add an anonymithny network then

<kiersten5821:matrix.org> and tx proxy

<kiersten5821:matrix.org> but still

<kiersten5821:matrix.org> simpler than knowing everything

<fr33_yourself> kiersten we can't protect stupid people haha. People need to show some self-initiative in defending themselves

<ofrnxmr:xmr.mx> youre talking about normies > <@kiersten5821:matrix.org> well yes add an anonymithny network then

<ofrnxmr:xmr.mx> What kinda normal ppl are storing 100gb and syncing for 20mins when they open their wallet?

<ofrnxmr:xmr.mx> And arent behind a nat? And can sync their eallet when away from home?

<fr33_yourself> what is a nat?

<kiersten5821:matrix.org> even power users would be unable to run nodes under the 100 mb blocks though

<ofrnxmr:xmr.mx> @kiersten5821:matrix.org: Thats like 6 years away

<ofrnxmr:xmr.mx> Were not hitting 100mb in 2026/2027

<fr33_yourself> and ofrn, you really think some of the current monero miners could consistently handle 99mb blocks tomorrow? What is is the maximum you think they could handle right now if we had FCMP

<ofrnxmr:xmr.mx> On rct? No

<ofrnxmr:xmr.mx> Not all of the fixes are upstream yet

<ofrnxmr:xmr.mx> On fcmp, yes

<fr33_yourself> Really that's surprising. I honestly didn't think miners would be able to handle that after FCMP

<ofrnxmr:xmr.mx> P2pool miners? Probably not as currently designed since small inputs arent easy to consolidate without filling blocks as it is

<fr33_yourself> I figured your initial numbers with 1mb blocks were the upperbound haha 😅

<ofrnxmr:xmr.mx> After fcmp its almost not afforable

<ofrnxmr:xmr.mx> For solo and pool miners, big blocks np

<ofrnxmr:xmr.mx> funny thing though, selfish mining large blocks favors the selfish miner

<fr33_yourself> I guess we will find out eventually haha. I see scaling and then lastly (possible) quantum as the final bosses of Monero

<ofrnxmr:xmr.mx> selfish meaning witholding txs**

<kiersten5821:matrix.org> there also are intermediate power users who dont know it all... when you tell someone who cares "input withholding attack" and they say how do i fix it it's way more effective to say "run a node" than "ah yeah well check if the wallet software is cacheing the tx and etc etc and yeah i dont know if the official wallet-gui does [... too long, see mrelay.p2pool.observer/e/0qPEtfQKMVZZUmFm ]

<ofrnxmr:xmr.mx> When the miner withholding txs submits their block, the other nodes have to stop what theyre doing to sync the unknown txs

<fr33_yourself> yeah whatever happened to tevador's share or perish? Is that going to get implemented or not looking likely

<fr33_yourself> @ofrnxmr:xmr.mx: That's a big problem

<ofrnxmr:xmr.mx> Not atm, the convos sorta just fizzled out

<fr33_yourself> Yeah that was what I observed last time i was here

<ofrnxmr:xmr.mx> @kiersten5821:matrix.org: Easier: here friend, use my node

<ofrnxmr:xmr.mx> Most people dont even have computers

<fr33_yourself> It is true that ASIC mining algos have greater barriers to selfish mining and disincentives (larger sunk capital investments in a highly specific device), but it is harder for an ASIC algo to respond / counter a selfish mining attack afterward. As typically there aren't idle ASICs lying around that can come online to counter

<ofrnxmr:xmr.mx> I would honestly say that probably 8/10 txs on chain are done via a remote node

<ofrnxmr:xmr.mx> Remote as in a node not controlled by the sender

<ofrnxmr:xmr.mx> Its not like 9/10 txs are via local nodes and we're cutting off a large portion of users. i used to run my main node on my phone

<ofrnxmr:xmr.mx> But i stopped because the pruned node is too big for my 128gb phone

<kiersten5821:matrix.org> 20% is big

<fr33_yourself> I would say that Monero is generally safe against a selfish mining attack from historical miners on the network, but Qubic proved that a bad outside actor can "snowball effect" the growth of their hashrate once they start successfully earning a disproportionately high share of block rewards relative to their hashrate. Only a bad outside actor or gov would have the incentive to do this though

<kiersten5821:matrix.org> large blocks favor the bigger miner even when everyone is honest, that's why bitcoin people made the fast relay network > <@ofrnxmr:xmr.mx> funny thing though, selfish mining large blocks favors the selfish miner

<ofrnxmr:xmr.mx> ?

<ofrnxmr:xmr.mx> mining large any blocks favor a node that can propagate the block before you, or a node will ignore blocks that you mine (selfish mining)

<fr33_yourself> Eventually mining of Monero will be highly specialized and more centralized. Likely dominated by botnets and people with cheap electric + cheap high bandwidth. The key concern is that you get big farms that control most of the hashrate. Pools aren't a problem as people can exit and join pools very quickly. Not so actual physical farms. This is one of the issues with ASICs.

<ofrnxmr:xmr.mx> the size of the miner only matters as it relates to the node's connectivity or the ability to orphan your blocks maliciously. This applies to any size block

<kiersten5821:matrix.org> @ofrnxmr:xmr.mx: no this is factually wrong bitcoinfibre.org/faqs

<kiersten5821:matrix.org> if you have a miner with 90% hashrate and one with 10% the one with 10% will get << 10% of the blocks if you have block verification time large

<kiersten5821:matrix.org> like assume it is 1 min verif 2 min average target

<kiersten5821:matrix.org> even if you start off with 90/10 assumption

<kiersten5821:matrix.org> almost 50% of the computation time of the 10% miner is wasted on an outdated chaintip

<kiersten5821:matrix.org> exactly why bitcoin dudes made fast relay network

<kiersten5821:matrix.org> large blocks lead to massive miner centralization

<kiersten5821:matrix.org> of course same advantage applies even with split like 30/20/10/smaller% miners, the bigger miners are always making more blocks than they deserve proportionally the larger the block size gets

<ofrnxmr:xmr.mx> Block verif time does not grow with block size > <@kiersten5821:matrix.org> if you have a miner with 90% hashrate and one with 10% the one with 10% will get << 10% of the blocks if you have block verification time large

<ofrnxmr:xmr.mx> The majority of the block size is the txs. the small miner's node has already verified the txs

<ofrnxmr:xmr.mx> I'm about to go do something else, but the first link doesnt confirm what youre saying

<ofrnxmr:xmr.mx> Bitcoins "compact blocks" are similar (or the same) as monero's fluffyblocks

<kiersten5821:matrix.org> the link explains compact blocks aren't enough. additionally as block size grows verif time obviously grows as the number of unseen tx grows

<ofrnxmr> the node verifies txs

<jbabb:cypherstack.com> > <@gingeropolous> anyone care to weigh in? paste.centos.org/view/raw/bd8c6052 . Running into a finicky glitch in monerosim where some user wallets sometimes don't send txs. it seems to be unique to shorter simulations (when there aren't a lot of chain outputs), so i think there's some merit to it. For those that d [... too long, see mrelay.p2pool.observer/e/gIiWxvQKRDNCUDly ]

<jbabb:cypherstack.com> I had this issue with cuprate-regtest: I solved it by mining more so there were more outputs from which to select. could you create more inputs so their selection algos converge on usable outputs?

<ofrnxmr:xmr.mx> Still sounds like a bug/oversight