04:05:05 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 https://mrelay.p2pool.observer/e/6_Cns_QKa3FJZUlZ ] 04:12:51 Theres a chart of verification times somewhere 04:14:21 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? 04:19:14 It takes much longer to generate them than it takes to verify them 04:20:12 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 04:20:21 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. 04:20:50 if valid, the inputs take virtually the same amount to verify in bulk as theyndk separarely 04:21:16 So sending sixteen 8in txs takes ~same verify time as one 128in 04:21:28 But the 8ins use more bandwidth and storage 04:23:15 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 04:24:15 7.5kb / 1mb 04:25:24 Er no, damn whats the new penalty free block aiE again? 04:28:57 @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 04:29:17 it's getting raised from the current 300 kb? 04:29:41 Maybe he's just talking hypothetically like after the dynamic block algo kicked in 04:31:19 7.5/625kb 04:31:41 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??? 04:32:20 What makes FCMP so much heavier and slower than the current version? 04:32:32 No 04:33:00 Monero uses fluffy blocks. When a block is mined, it doesnt send the whole block (with txs) 04:33:15 It only sends txs if the recipienr node is missing them 04:33:44 This would be about 80tx per block and 57,600 per day. > <@ofrnxmr:xmr.mx> 7.5/625kb 04:33:47 So txs are verified as they arrive on your mode, not all at once when the block is mined 04:34:07 @fr33_yourself: We do about 40 right now @ 25-40k per day 04:35:16 @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? 04:42:57 We pushed blocks to 30mb without issue (after fixes) 04:43:23 And fcmp really made little to no difference. The issues would have been problem with rct 04:44:30 Verification wasnt an issue. Issue was propagation delays due to inefficient tx and block relay + other strange design decisions 04:44:32 @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. 04:45:20 most of the bigger performance related debt has been tackled on stressnet 04:45:24 So you think the FCMP stressnet could handle 30mb blocks? 04:45:50 @ofrnxmr:xmr.mx: was Ooo hardcarrying? 04:45:59 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 04:46:19 @fr33_yourself: No, he's been 👻 for a little while 04:46:56 Jberman dealt with the vast majority of the performance issues, and 0xfffc boog and berman did the tx relay v2 04:47:35 @fr33_yourself: Without breaking a sweat 04:47:41 so its raised to 625kb? 04:47:43 What do you think the upperbound blocksize is with current technology post FCMP? 04:48:05 @kiersten5821:matrix.org: Penalty free zone bumped from 300kb to 625 , yea 04:48:15 Upperbound meaning miners don't fall out of sync with each other and things break 04:48:17 @fr33_yourself: 99.9mb 04:49:00 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 04:49:00 And not because od performance but because of growth and bandwidth 04:49:23 @kiersten5821:matrix.org: He also doesnt listen 04:49:59 I told him on simplex before he came here, and it took like 2 days for him tk run the node as instructed 04:50:08 my pc can only verify 2.4 block/s it will take literally 2 minutes to sync this block > <@ofrnxmr:xmr.mx> 99.9mb 04:50:34 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 04:50:51 Your nlde verifies txs as they enter the txpool 04:51:07 node not always live 04:51:29 Well then you wouldnt be able to catch up :P 04:52:01 at 30mb blocks nobody fell behind 04:52:16 Even 1gb ram 4core potatoes that we tested on 04:52:40 But if my node offline for a week then it will take a week to catch up... 04:52:59 Get a better node ❤️‍🩹 04:53:06 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? 04:53:21 trust me no one will sync a node if it takes a week 04:53:27 and therefore no one will have privacy from the node operator 04:53:31 because they will use remote node 04:53:58 @fr33_yourself: Thats a fact of large blocks regardless. Either you pony up and run the infra or some(ne else will 04:54:09 @kiersten5821:matrix.org: They can use a VPN or connect over Tor to a Tor node 04:54:27 The opposite is to cripple the network and have it only be used for some niche demographic 04:55:22 @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 04:55:23 wont be able to run nodes on your 128gb sd card rasp pi forever 04:55:36 @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 04:55:44 Cant run your gaming computer on 64mb ram forever either 04:55:51 in the current system dont you need to download ALL the block data? 04:56:02 You do need to 04:56:19 Well, if you run a pruned node you can use --sync-pruned-blocks to skip some 04:56:42 But that only applies to the checkpointed section of the blockchain 04:57:04 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? 04:57:27 @ofrnxmr:xmr.mx: If you use a remote node you only need to sync from the restore height of the wallet in question 04:57:28 Oh, for wallets. No, wallets downlaod pruned blocks 04:57:38 Much much less data than a node 04:57:52 I think the whole chain currently takes loke 30gb to sync from 0 04:58:27 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 04:59:02 I dont see how everyone running a node makes any sense at all period 04:59:31 it doesn't but it still shouldn't be astronomical cost 04:59:32 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 04:59:59 bitcoin spv has 0 privacy you send all addresses to the server 05:00:01 that is how electrum works 05:00:01 it doesnt compare 05:00:10 Our remote nodes are identical to local nodes 05:01:02 So remote nodes in Monero are more secure against being fed bad block data right? Than most SPV wallets on Bitcoin? 05:01:32 No 05:02:21 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 05:03:11 You cant just use any random node you found on a dark alley and expect to be using good data 05:05:09 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 05:05:13 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 05:05:30 @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 https://mrelay.p2pool.observer/e/gJWFtfQKQmxlQ3hQ ] 05:06:06 @fr33_yourself: Thats why you and your recipient shouldnt be using the same node 05:06:17 i think the block size should be capped, just like bitcoin 05:06:22 If everyone uses cake's node, you dont know if cake actually relayed it 05:06:45 @kiersten5821:matrix.org: Lmfao 05:06:46 Theres a coin for that: bitcoin 05:07:06 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 05:07:12 monero should not be locking max privacy behind insane hardware requirement 05:07:33 you know there are problems with remote nodes and chainal are running them because of that 05:07:38 Monero isn't very useful if it doesn't scale 05:07:46 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 05:08:16 @kiersten5821:matrix.org: Sounds very ill-informed to me 05:08:31 Chainanal running nodes is the biggest joke ive ever heard 05:09:01 some of us know far better how to trace a monero tx than chainanals circus act 05:09:10 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 05:09:30 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. 05:09:38 and how many rpc nodes have chainanal ran? Like zero 05:09:43 Cuz theyre retarded 05:10:36 how would you even prove an rpc node is not run by chainal 05:10:41 And the witholding attack doesnt work if you re-submit the same tx using a diff node (the same decoys are used) 05:10:49 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. 05:10:58 But once again, this isn't a protocol issue 05:10:59 @kiersten5821:matrix.org: Because we have researchers monitoring the netowkr? 05:11:22 We had bad actors running rpc nodes that cause you to lose money 05:11:59 @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? 05:12:02 The spy nlde used on chainanal leak video was... a proxy to one of OUR nodes 05:12:12 They didnt even run their own node 05:12:41 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? 05:12:46 @kiersten5821:matrix.org: I dont know the specifics, but the wallet caches the decoys and will reuse them 05:13:24 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? 05:13:36 The tx is already generated and just needs to be resubmit using submitrawtransaction 05:13:44 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? 05:14:02 Featherwallet does this by default by submitting the tx to every node that configured 05:14:23 does the wallet-gui or cli do that though 05:14:49 Multi-submit? No 05:15:03 Monero-gui connecys you to random malicious nodes 🧠 05:15:11 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" 05:15:21 thats not true. 05:15:23 yeah i remember somehow someone used simple mode and then the tx had an 8 monero fee 05:15:36 Running youe own node does not have max privacy 05:15:42 man its crazy to say nodes will be so expensive normal users cant run them 05:15:49 well yes add an anonymithny network then 05:15:55 and tx proxy 05:15:59 but still 05:16:07 simpler than knowing everything 05:16:11 kiersten we can't protect stupid people haha. People need to show some self-initiative in defending themselves 05:16:14 youre talking about normies > <@kiersten5821:matrix.org> well yes add an anonymithny network then 05:16:39 What kinda normal ppl are storing 100gb and syncing for 20mins when they open their wallet? 05:16:55 And arent behind a nat? And can sync their eallet when away from home? 05:17:33 what is a nat? 05:17:42 even power users would be unable to run nodes under the 100 mb blocks though 05:18:04 @kiersten5821:matrix.org: Thats like 6 years away 05:18:16 Were not hitting 100mb in 2026/2027 05:18:34 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 05:18:46 On rct? No 05:18:55 Not all of the fixes are upstream yet 05:19:00 On fcmp, yes 05:19:41 Really that's surprising. I honestly didn't think miners would be able to handle that after FCMP 05:20:09 P2pool miners? Probably not as currently designed since small inputs arent easy to consolidate without filling blocks as it is 05:20:14 I figured your initial numbers with 1mb blocks were the upperbound haha 😅 05:20:32 After fcmp its almost not afforable 05:21:05 For solo and pool miners, big blocks np 05:22:00 funny thing though, selfish mining large blocks favors the selfish miner 05:22:02 I guess we will find out eventually haha. I see scaling and then lastly (possible) quantum as the final bosses of Monero 05:22:22 selfish meaning witholding txs** 05:22:45 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 https://mrelay.p2pool.observer/e/0qPEtfQKMVZZUmFm ] 05:22:46 When the miner withholding txs submits their block, the other nodes have to stop what theyre doing to sync the unknown txs 05:22:52 yeah whatever happened to tevador's share or perish? Is that going to get implemented or not looking likely 05:23:21 @ofrnxmr:xmr.mx: That's a big problem 05:23:22 Not atm, the convos sorta just fizzled out 05:23:41 Yeah that was what I observed last time i was here 05:23:52 @kiersten5821:matrix.org: Easier: here friend, use my node 05:24:30 Most people dont even have computers 05:25:15 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 05:25:20 I would honestly say that probably 8/10 txs on chain are done via a remote node 05:25:33 Remote as in a node not controlled by the sender 05:27:17 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 05:27:35 But i stopped because the pruned node is too big for my 128gb phone 05:27:36 20% is big 05:27:49 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 05:33:57 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 05:36:43 ? 05:38:30 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) 05:38:37 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. 05:39:34 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 05:45:55 @ofrnxmr:xmr.mx: no this is factually wrong https://bitcoinfibre.org/faqs/ 05:46:25 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 05:46:37 like assume it is 1 min verif 2 min average target 05:46:49 even if you start off with 90/10 assumption 05:47:06 almost 50% of the computation time of the 10% miner is wasted on an outdated chaintip 05:47:40 exactly why bitcoin dudes made fast relay network 05:48:40 large blocks lead to massive miner centralization 05:50:49 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 05:53:38 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 05:54:37 The majority of the block size is the txs. the small miner's node has already verified the txs 05:56:02 I'm about to go do something else, but the first link doesnt confirm what youre saying 05:56:31 Bitcoins "compact blocks" are similar (or the same) as monero's fluffyblocks 14:00:25 the link explains compact blocks aren't enough. additionally as block size grows verif time obviously grows as the number of unseen tx grows 14:11:10 the node verifies txs 15:04:21 > <@gingeropolous> anyone care to weigh in? https://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 https://mrelay.p2pool.observer/e/gIiWxvQKRDNCUDly ] 15:04:21 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? 15:28:38 Still sounds like a bug/oversight