03:48:49 <DataHoarder> given hash_to_ec was renamed to biased_hash_to_ec in fcmp monero fork, should hash_to_p3 also get renamed? the function is equivalent except input arguments
06:08:45 <br-m> <spackle> If the Monero network cannot handle the volume the scaling design allows, the formulas are only a fantasy. Small blocks and high fees make a network unusable; so does a malfunctioning daemon.
06:12:09 <br-m> <spackle> All I would ask if that some consideration be made for demonstrated daemon performance. I might suggest another scaling metric, let's call it 'runway.' This is how long the network can operate under maximum scaling conditions before it reaches a known limitation which requires intervention. Right now on mainnet the runway is s [... too long, see https://mrelay.p2pool.observer/e/nZf46cMKbEF3T0U2 ]
06:32:29 <br-m> <ofrnxmr> what makes you say half a day?
06:33:34 <br-m> <ofrnxmr> If prepared, i think a 600mb txpool is bad enough
06:33:57 <br-m> <ofrnxmr> So more like, however long it takes to spam that many txs
06:36:19 <br-m> <ofrnxmr> But thats not necessarily a scaling problem, just poorly designed.
06:36:19 <br-m> <ofrnxmr> are you referring to block growth over 12hrs?
06:38:24 <br-m> <spackle> I gave that estimate in the interest of making my point while also being generous.
06:38:58 <br-m> <ofrnxmr> but what is the estimate referring to, block growth?
06:39:34 <br-m> <spackle> I agree there is more than one issue which arises on that timeframe. So long as everyone understands that, it frames the design discussion correctly.
06:40:21 <br-m> <ofrnxmr> The good thing is that a lot of these issues are being fixed in the immediate term (before fcmp hard fork or scaling changes)
06:41:52 <br-m> <spackle> I stated half a day as that is a conservative rough estimate for how long it might take to hit the long term median limit of 30 MB.
06:44:35 <br-m> <spackle> If the daemon is unable to handle volume up to this limit, the network fails within hours. If the daemon can handle volume up to this limit, the network is hardened against all possible circumstances for over two months.
06:51:06 <br-m> <ofrnxmr> I think we'll be able to push stressnet to 30+mb blocks, but id like to wait for some of the efficiency fixed to be in first. 1000x fees is 0.03xmr for a 1:2 tx on mainnet today. Id probably argue that scaling could be slowed by an order of magnitude
06:53:40 <br-m> <ofrnxmr> If txpool is fixed (if we can handle large txpools), then we could retain txs for longer than 3 days and increase the max txpool size
06:54:05 <br-m> <ofrnxmr> Which would allow scaling to be slowed down a bit w/o dropping txs
07:06:52 <br-m> <articmine> Technically to max out the proposed cap on the short term median one needs 32 MB, assuming a 1 MB penalty free zone 
08:03:26 <br-m> <articmine> This provides over 2 months 
08:03:53 <br-m> <articmine> 50000 blocks to be exact 
08:16:14 <br-m> <321bob321> https://signal.org/blog/spqr/
08:16:14 <br-m> <321bob321> Signal Protocol and Post-Quantum Ratchets
08:48:47 <br-m> <spackle> @articmine: If this is the network stability target it should be an acknowledged performance requirement by developers (jberman and jeffro specifically).
10:52:15 <br-m> <spackle> In my opinion the goal should be to agree upon a robust design with the 50000 block runway, and move forward as soon as possible.
10:52:57 <br-m> <spackle> A 50000 block runway would be a fortress; something to be stood upon while saying with confidence that other proposals are unnecessary distractions. If we cannot stand on that foundation, then other proposals become far more enticing.
15:43:50 <br-m> <articmine> The FCMP++ hard fork effectively quadruples the size of transactions before even considering verification time. 
15:43:50 <br-m> <articmine> My take is that if we cannot stand on this fortress we need to delay the hard fork until we can.
15:45:16 <br-m> <articmine> It is the prudent course of action.
15:50:15 <br-m> <boog900> the scaling code is in now though, we are vulnerable now. 
15:50:46 <br-m> <boog900> AFAIK no changes were made to it on the stressnet fork 
15:51:33 <br-m> <articmine> The stressnet is currently working on the current scaling with a 50x long-term median  and a maximum block size of 100x the penalty free zone. This gives a 30 MB target for 300000 minimum penalty free zone 
15:52:54 <DataHoarder> At least qubic can only put max 20 transactions per block of theirs due to their choices :)
15:53:18 <DataHoarder> They will push median down!
15:54:16 <br-m> <articmine> @boog900: Which is why the existing vulnerability  needs to  be addressed before we increase the transaction size by a factor of 4 for starters
15:55:05 <br-m> <boog900> we can reduce the max block growth for the next HF 
15:56:19 <br-m> <articmine> We already are from 50x to 16x on the short term median 
15:57:22 <br-m> <boog900> yeah I know, so no need to delay the HF right? 
15:57:47 <br-m> <articmine> It is the prudent way to go 
15:59:00 <br-m> <boog900> if we make the block growth slower for the next HF that could actually help our situation 
15:59:35 <br-m> <boog900> so delaying it would be leaving us with the faster block growth for longer 
16:01:07 <br-m> <articmine> Not really, because the HF itself could spur a major growth in adoption. This could easily be further compounded by a legal defeat of blockchain surveillance in the US courts 
16:01:34 <DataHoarder> Delaying it just makes an attack take longer
16:01:50 <DataHoarder> Unless there's a plan on how to act or a limit it'll just take more time 
16:01:51 <br-m> <boog900> and tomorrow qubic could decide they want to fill all their blocks to the max 
16:02:01 <DataHoarder> ^
16:02:08 <br-m> <boog900> they have already demonstrated they can get more than 50% of blocks  
16:02:09 <br-m> <spackle> Having the 50000 block runway is plenty prudent. No need for a delay so long as the network can meet that minimum robustness requirement.
16:02:17 <DataHoarder> They already pad their blocks with garbage txs
16:02:19 <DataHoarder> That cost them nothing as it's their own
16:02:35 <br-m> <articmine> No it provides time to fix the underlying code issues that have been identified in stressnet 
16:03:41 <DataHoarder> I mean if next hardfork the growth is slowed
16:03:42 <br-m> <articmine> @spackle: I am suggesting a delay until we get the 50000 block runway
16:03:55 <DataHoarder> Instead of capped or logarithmic 
16:04:03 <br-m> <boog900> the real solution would be to put out a soft fork limiting block growth tomorrow 
16:04:20 <br-m> <boog900> but that would be controversial
16:04:28 <DataHoarder> Instead of exponential
16:04:33 <br-m> <boog900> although I do think it is justified 
16:05:13 <br-m> <articmine> No the real solution is to fix the underlying code issues 
16:07:29 <br-m> <spackle> Dramatic improvements are already in place. The 50000 block runway is absolutely possible without any delay. Worst case is that it requires some compromise on the scaling parameters.
16:08:02 <DataHoarder> more controversial dns checkpoints limiting it lol
16:08:22 <br-m> <boog900> if it was that easy it would have been done already, delaying the HF wont make it happen faster IMO
16:08:38 <br-m> <boog900> and could make our situation worse if we can limit block growth in the next HF 
16:10:48 <DataHoarder> This goes back to last MRL, got someone with time to refactor and cleanup technical debt, implement, then have also someone else to review?
16:11:04 <br-m> <boog900> take this PR as an example of the amount of work and timeframe: https://github.com/monero-project/monero/pull/9135
16:11:05 <DataHoarder> Besides a plan or growth method
16:11:20 <br-m> <articmine> @boog900: I am not convinced . This only came to light because of the threat of  an increase in blocksize
16:11:47 <br-m> <boog900> @boog900: that PR was also a direct vuln fix btw not just an improvement 
16:12:25 <DataHoarder> The solution is easy. Fork monero into AINero and only allow vibe code  
16:12:30 <br-m> <articmine> Which makes point 
16:12:33 <DataHoarder> And reviewed by ai
16:15:44 <br-m> <articmine> I was there for the 2017 HF where the penalty free zone went from 40000 bytes to 60000 bytes while the transaction size was increased 30x. 
16:15:44 <br-m> <articmine> To put it mildly the result was a fiasco 
16:17:05 <br-m> <articmine> It was what  led me to get heavily involved with Monero scaling 
16:21:28 <br-m> <articmine> A scaling HF has to be rushed through which actually provided cover for the HF fix of a totally very serious vulnerability that affected not only Monero but all the other Cryptonote coins
16:22:44 <br-m> <articmine> This vulnerability had nothing to do with scaling 
16:24:41 <br-m> <boog900> If we can limit block growth to ~16 MB for 2 months at the next HF I see no reason to delay it 
16:26:29 <br-m> <boog900> it might buy us a bit more time to fix issues but I don't think enough to justify putting it off when it itself makes the situation better by reducing block growth
16:26:46 <br-m> <articmine> It is very heavily priced above 16 MB in my proposal but not a hard cap 
16:27:12 <br-m> <articmine> The hard cap is at 32 MB
16:27:36 <br-m> <articmine> For 50000 blocks 
16:28:26 <br-m> <boog900> :( 
16:29:22 <br-m> <articmine> Think a stiff spring as opposed to a brick wall at 16MB
16:30:37 <br-m> <articmine> If a train hits a stiff spring is actually safer 
16:30:50 <br-m> <boog900> miners don't have cost
16:31:24 <br-m> <spackle> If 16 MB would be safe to deploy without delay, why is reducing the hard cap to 16 MB unreasonable?
16:31:38 <br-m> <articmine> Sure they do if they loose up to the entire block reward 
16:32:26 <br-m> <articmine> @spackle: It destroy surge for holiday shopping for example
16:32:27 <br-m> <boog900> @articmine: sure but that is not enough IMO 
16:32:57 <br-m> <spackle> No delay, the deployment is safe, and the scaling is enabled in time for the holidays.
16:32:57 <br-m> <boog900> @articmine: when has that ever been shown in monero
16:33:40 <br-m> <spackle> I was about to say the same thing, it doesn't seem to have an empirical backing as a standard.
16:33:45 <br-m> <articmine> Actually it has
16:34:04 <br-m> <boog900> again building our systems to the numbers from VISA is not the way to do things IMO 
16:34:07 <br-m> <spackle> At a growth of multiple the existing transaction rate?
16:34:25 <br-m> <articmine> This is based upon the surge factor for VISA
16:34:56 <br-m> <spackle> Indeed, but not Monero. Monero has not shown that behavior.
16:35:00 <br-m> <articmine> They actually tested at 20x
16:35:27 <br-m> <ofrnxmr:xmr.mx> I think holiday shopping surges can be accomodated by larger txpools > <@articmine> It destroy surge for holiday shopping for example
16:35:56 <br-m> <articmine> @spackle: Because many transactions are investment / speculation
16:37:06 <br-m> <ofrnxmr:xmr.mx> imo, atm, i think the txpool is one of the shittiest pieces of monero atm
16:37:45 <br-m> <articmine> Setting the standard at 32 MB
16:37:49 <br-m> <spackle> I do not understand the insistence on designing a system around behavior it does not exhibit, but I'll excuse myself from the conversation as I see it being beside the point. 
16:37:53 <br-m> <spackle> I return to my earlier thought, if 16 MB is safe at deployment then set it to 16 at deployment and have it increase to 32 after a delay to allow for additional development.
16:37:55 <br-m> <articmine> is way more robust 
16:37:56 <br-m> <sgp_> @ofrnxmr:xmr.mx  I think everyone is for improving the txpool handling to allow for a much bigger queue
16:38:16 <br-m> <spackle> No delay, safe deployment, and future holiday shoppers can delight in their surge capacity.
16:38:23 <br-m> <boog900> @spackle: just set at 16 forever 
16:38:24 <br-m> <sgp_> Am I wrong, is anyone for a purposely sucky txpool? Lol
16:38:39 <br-m> <boog900> it still allows for growth beyond 16 after 2 months 
16:38:47 <br-m> <spackle> @boog900: I would be fine with that, but I am hoping that today's theme is compromise.
16:38:49 <br-m> <articmine> @sgp_: If course not .
16:39:05 <br-m> <ofrnxmr:xmr.mx> @sgp_: i dont know, but its been bad forever and it gets ignored or bandaided
16:39:13 <nioc> what is the historical holiday tx surge for monero?
16:39:18 <br-m> <articmine> This is not a replacement for throtelling adoption 
16:39:40 <br-m> <boog900> we don't need to follow VISAs numbers, we are a completely different system, there are no guarantees we are used the same way 
16:39:47 <br-m> <articmine> I have seen 2-3x
16:39:55 <br-m> <boog900> VISA has no 10 block lock 
16:39:56 <br-m> <ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: Jberman & 0x working on it, but there are probably h1 quality issues with it
16:40:08 <br-m> <ofrnxmr:xmr.mx> @boog900: Visa had a 48hr block lock :P
16:40:24 <br-m> <sgp_> A large txpool is probably a failure case in your mind ArticMine, is that true? It means queued transactions waiting for a confirmation, potentially for a while. Would you argue a large txpool is an indicator that the block size isn't big enough?
16:40:34 <br-m> <boog900> @ofrnxmr:xmr.mx: exactly ... different :D
16:40:41 <br-m> <ofrnxmr:xmr.mx> @boog900: So they have a 48hr backlog to get 1 conf
16:41:07 <br-m> <articmine> Visa has  2-4 day settlement. time vs a 20 min 10 block in Monero 
16:41:13 <br-m> <ofrnxmr:xmr.mx> @sgp_: I argue that a txpool that grows tk the point of dropping txs is an issue
16:41:14 <br-m> <boog900> @ofrnxmr:xmr.mx: but that doesn't lock the "change output"
16:41:31 <br-m> <articmine> We beat VISA hands down there
16:41:50 <br-m> <ofrnxmr:xmr.mx> @boog900: Its all IOU's
16:42:05 <br-m> <boog900>  why don't we have a 2000 surge factor then? 
16:42:19 <br-m> <boog900> we are not the same system 
16:42:49 <br-m> <articmine> @boog900: There is no point
16:43:11 <br-m> <ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: btc has a 300mb(?) Tx pool by default, that expires (? Weeks? Never?). Monero has a 72hr expiry, and a txpool that is 2x the size while txs are 5x the size. (soon to be 20x)
16:44:21 <br-m> <articmine> @ofrnxmr:xmr.mx: The tx pool size needs to increase
16:44:27 <br-m> <sgp_> Ofrn can we simply assume unlimited time in unlimited txpool for a bit pls? At least for this scaling discussion
16:44:30 <br-m> <ofrnxmr:xmr.mx> Monero cant, atm, expand the txpool size because it breaks things
16:44:56 <br-m> <articmine> @sgp_: This creates a vulnerability
16:45:21 <br-m> <articmine> Which is exploited in Bitcoin 
16:45:49 <br-m> <ofrnxmr:xmr.mx> I would hope that after fixes that the pool size can be expanded to sizes large enough to prevent dropping of txs while blocks are catching up
16:46:06 <br-m> <boog900> @articmine:monero.social: why do you think we should conform to VISAs numbers if they have never been shown in Monero?
16:46:13 <br-m> <sgp_> There's no way to 100% guarantee no dropping of txs that I can see
16:46:47 <br-m> <articmine> @boog900: It is the ratio of the average tx rate to the peak
16:47:14 <br-m> <sgp_> You could set the txpool limit to 100 TB but it could still fill up and need to drop txs
16:47:15 <br-m> <boog900> @articmine: exactly for, their txs
16:47:29 <br-m> <articmine> If Monero is used as peer to peer cash that ratio should remain the same
16:47:58 <br-m> <articmine> It is the same use case
16:48:26 <br-m> <sgp_> Bitcoin allows each node to configure a max txpool size fwiw. Nodes can increase it from the default to drop txs less often
16:48:28 <br-m> <spackle> Things can be used differently in fulfillment of the same use, all evidence points to this being the case for Monero vs VISA.
16:48:30 <br-m> <boog900> its really not and it has been demonstrated in the past this does not hold 
16:48:51 <br-m> <boog900> monero only does 2 to 3x 
16:49:38 <br-m> <articmine> Because there is investment and speculation in Monero on chain 
16:49:39 <br-m> <boog900> so what 10x is still more than enough? 
16:50:08 <br-m> <articmine> People do not use VISA to buy ViSA stock
16:51:10 <br-m> <boog900> exactly we are different.
16:51:16 <br-m> <articmine> But they do use the Monero network to invest inMonero
16:51:22 <br-m> <boog900> why kill ourselves to conform? 
16:51:31 <br-m> <spackle> Indeed, it is precisely why a different approach is justified.
16:51:37 <br-m> <boog900> when we haven't got close to these numbers 
16:52:16 <br-m> <boog900> and do we track VISA forever 
16:52:33 <br-m> <ofrnxmr:xmr.mx> @sgp_: Math
16:52:34 <br-m> <boog900> what if VISA reports 40x due to change in consumer habits? 
16:52:47 <br-m> <articmine> Can't we just fix the problem rather than argu over how to hide it
16:53:06 <br-m> <articmine> argue
16:53:08 <br-m> <boog900> there is always a limit
16:53:17 <br-m> <boog900> we can't have 1 TB blocks 
16:53:27 <br-m> <boog900> I think 32 MB is too much for the short term 
16:53:32 <br-m> <articmine> @boog900: Not yet
16:53:35 <br-m> <boog900> 16 is much safer 
16:54:22 <br-m> <articmine> What is safer is to fix the underlying problem 
16:54:51 <br-m> <spackle> If 16 is sufficient for deployment, then set it to 16 at deployment. Delaying the FCMP hard fork for the sake of excessive surge design seems like a very bad idea to me.
16:55:22 <br-m> <spackle> One might describe the underlying problem as a cap that is set too generously, and indeed that can be fixed if needed.
16:55:39 <br-m> <articmine> @spackle: You are actually building reseliance
16:56:30 <br-m> <articmine> Arguing against fixing bugs I will not support 
16:56:36 <br-m> <spackle> Resilience is being built regardless. The issue at hand, as I see it, is that the resilience needs to be at an acceptable level at deployment.
16:56:48 <br-m> <spackle> Nobody is arguing against fixing bugs.
16:57:51 <br-m> <sgp_> I'm not arguing against fixing bugs, I'm arguing against a feature that exposes the network to a likely very significant security risk. Even you agree it's a risk because if it wasn't, we'd allow unlimited txs today (if there's no risk, why not!?)
16:58:17 <br-m> <articmine> Please 
16:58:45 <br-m> <boog900> @articmine:monero.social: where can I find data on VISAs transaction numbers?
17:00:55 <br-m> <articmine> Look at their financial reports. This. gives their average tx rate. Then they put out press releases where they brag about their max capacity.
17:01:23 <br-m> <articmine> They do hide their max capacity 
17:01:50 <br-m> <articmine> Most of the time
17:02:37 <br-m> <boog900> so we are basing the security of our network off of VISAs marketing team? 
17:03:17 <br-m> <boog900> and not our own numbers? 
17:06:05 <br-m> <boog900> I just don't know why we need VISAs reported surge factor
17:07:10 <br-m> <ofrnxmr:xmr.mx> I think a surge to capped 16mb blocks during short term median is enough
17:07:34 <br-m> <articmine> https://bitinfocharts.com/comparison/transactions-price-xmr.html#log&alltime
17:09:13 <br-m> <articmine> @ofrnxmr:xmr.mx: Which is what I am proposing when pricing is factor in
17:10:05 <br-m> <boog900> You can go above 16 with what you are proposing so it is not a cap 
17:10:06 <br-m> <articmine> People just want to crash into a brick wall rather than soften the blow with a spring 
17:10:38 <br-m> <boog900> Soften at 8 or 10 or 12 
17:11:22 <br-m> <articmine> I am not agreeing to further restrictions on Monero adoption 
17:11:57 <br-m> <articmine> People are just not satisfied 
17:12:33 <br-m> <spackle> I would be unsatisfied with a scaling delay on the FCMP hard fork.
17:12:35 <br-m> <articmine> ... there is just too much fud on this coming from Bitcoin 
17:12:58 <br-m> <ofrnxmr:xmr.mx> The hard cap is at 32mb? Im just saying halve that for the first fcmp hard fork
17:13:24 <br-m> <spackle> If a surge factor of 8 in the short term is what is needed for safe deployment, then I would readily support that as well.
17:13:29 <br-m> <articmine> @ofrnxmr:xmr.mx: I don't see why
17:14:14 <br-m> <ofrnxmr:xmr.mx> 32mb in under 100k blocks isnt sustainable imo
17:14:20 <br-m> <articmine> It will not satisfy the radicals anyway . Just take a look at the history of Bitcoin 
17:14:37 <br-m> <spackle> The scaling growth is exponential, whether 8 or 16. They are not ALL that different in the grand scheme of things.
17:15:17 <br-m> <spackle> This is not some dramatic change of course, it is bringing the scaling design into agreement with the state of daemon performance.
17:16:57 <br-m> <articmine> @spackle: There is a lot of politics and entrenched financial interests here
17:17:06 <br-m> <articmine> That are feeding fud
17:18:55 <br-m> <articmine> I have to look no further than this 10% proposal to see what is ready behind this
17:19:26 <br-m> <sgp_> you calling it the 10% proposal shows you haven't even looked at it lol. I already provided a 50% growth example
17:19:38 <br-m> <sgp_> Anything with perpetual 6x scaling per year is not rational. Period. I'm really sorry to say this so bluntly but it just makes no logical sense at all, and the community needs to know how dangerous it is. Call it "FUD" all you want
17:20:22 <br-m> <articmine> I have seen it. That is the ZCash spam attack in Monero example 
17:21:11 <br-m> <boog900> Monero would be unusable in under a day if someone maxed out block size on mainnet 
17:22:40 <br-m> <boog900> @articmine:monero.social:  why do we need to follow VISAs numbers
17:22:53 <br-m> <boog900> That they self report 
17:22:57 <br-m> <articmine> A fixed rate of growth regardless of demand is totally not rational
17:23:31 <br-m> <sgp_> ....it's a maximum allowed growth, akin to your proposal in that regard....
17:24:16 <br-m> <sgp_> (sorry I think I misread, ignore that ^)
17:24:30 <br-m> <articmine> @sgp_: You are not pricing growth
17:25:16 <br-m> <articmine> There are no medians in your proposal 
17:25:21 <br-m> <sgp_> transactions do not equal organic demand, they could be spam. Allowing spam to create more spam more quickly is a potential vulnerability in the design
17:25:54 <br-m> <articmine> @sgp_: How do you propose to tell them apart in Monero
17:26:04 <br-m> <articmine> Come on
17:26:40 <br-m> <articmine> Without pricing growth there is no spam control 
17:26:49 <br-m> <sgp_> I don't tell them apart. The proposal says in simple terms "assuming we can't tell them apart, we restrict like so to protect ourself in case it's spam"
17:27:06 <br-m> <sgp_> the spam control is the growing max block size
17:27:11 <br-m> <articmine> This is the problem with all the Bitcoin like coins 
17:27:25 <br-m> <articmine> @sgp_: No it is not
17:28:14 <br-m> <sgp_> the caps limit the potential network harms of spam
17:28:30 <br-m> <articmine> This fails with in the clear coins
17:28:47 <br-m> <boog900> Its irrational to believe we need to base our system off of a completely different one when it has never been shown in our system and it pushes our system right to its limits 
17:29:00 <br-m> <articmine> Which have the spam to prove it
17:29:38 <br-m> <sgp_> I don't follow, but if you're saying spam exists on Bitcoin, I agree. It exists everywhere and must be accounted for
17:30:15 <br-m> <articmine> It is way worse than vin Monero 
17:30:37 <br-m> <articmine> BCH ZCash Doge etc
17:31:08 <br-m> <sgp_> I don't know how we can say Monero spam isn't bad if we don't know which transactions are spam
17:31:53 <br-m> <ofrnxmr:xmr.mx> I think it would make sense to even add a fifth 10000x multiplier to break through the 16mb
17:32:47 <br-m> <ofrnxmr:xmr.mx> Make the spring cost so much that it cant be sustained as an attack. To compare to visa, visa charges 1.5-4% to use it
17:33:46 <br-m> <sgp_> 10000x is probably safe to use as a deterrent in practice if 1x is costly enough today, but we don't now if 1x (or even 10000x) will be costly in practice in the future
17:34:07 <br-m> <ofrnxmr:xmr.mx> Imo each tier should max out how far it can scale within the short term median
17:34:47 <br-m> <articmine> Just take a look at the average blocksize on Bitinfocharts for say XMR BCH BSV DOGE Zcsah even early BTC
17:34:50 <br-m> <sgp_> Can you organize your thoughts into your own proposal ofrn? I think it would help me keep track of the interweaving ideas and understand it better
17:35:22 <br-m> <articmine> ...and even early BTC 
17:35:59 <br-m> <articmine> We have a system that works and some people are hell bent on destroy it 
17:36:10 <br-m> <boog900> @ofrnxmr:xmr.mx: Miners still don't pay the cost, unless we add fee burning and what's the point just to reach VISAs reported numbers
17:36:12 <br-m> <sgp_> this is because the minimum fee is essentially 0 right? If there's free block space, spam will use it, that phenomenon?
17:36:16 <br-m> <ofrnxmr:xmr.mx> @articmine: i delete before i post, then post a few words. Lol. I'm not able to think of a best practoce, but i think what i just said makes sense
17:36:34 <br-m> <ofrnxmr:xmr.mx> @boog900: Yeah, miners dont even have to run nodes
17:37:10 <br-m> <articmine> @boog900: We have fee burning . It is called the pension
17:37:16 <br-m> <sgp_> in my proposal I make miners' use of the spring have the real cost in the form of a decreasing inflation reward
17:37:19 <br-m> <articmine> Penalty 
17:37:41 <br-m> <sgp_> the penalty is definitely useful for that purpose
17:38:03 <br-m> <spackle> I feel a dangerous level of scope creep lurking here. All I can say is that a scaling delay to FCMP would be a significant loss for Monero and I believe that idea should be resisted fiercely. It seems to me that only minimal changes may be needed to ensure we have a safe, scalable, functioning system that is deployed without hindrance.
17:38:15 <br-m> <boog900> Why do you answer that bit and not why we need to follow VISAs reported numbers
17:38:56 <br-m> <articmine> @spackle: The scope creep is the fear of peer to peer cash
17:39:23 <br-m> <boog900> @articmine: Its not enough IMO
17:39:36 <br-m> <articmine> Nothing is enough 
17:39:45 <br-m> <boog900> We have already seen a malicious actor mine at a significant loss 
17:40:01 <br-m> <articmine> For the radical small blockers
17:40:16 <br-m> <sgp_> as a reminder, to get to Visa's transaction throughput 10 years from now, Monero would need to start with a block size of 193 MB today and grow 50% per year for 10 years to get there (300 billion transactions per year)
17:40:25 <br-m> <articmine> Anyway this is not going anywhere 
17:40:35 <br-m> <boog900> I am literally saying 16 is enough 
17:41:26 <br-m> <spackle> I would say that whatever developers (jberman and jeffro) find to be a safe compromise position for deployment is enough.
17:42:24 <br-m> <ofrnxmr:xmr.mx> rip boog900, you don't make the cut
17:43:44 <br-m> <boog900> I'll take myself back to cuprate, needing to follow monerod's every (miss-)step
17:45:06 <br-m> <spackle> Perhaps poorly phrased, but I only mean that daemon performance should inform the short term scaling.
17:45:08 <br-m> <articmine> @sgp_: Why don't you start with 1MB in October 2008 and see what you get today at 50% per year
17:45:35 <br-m> <articmine> When the Bitcoin whitepaper was released 
17:46:12 <br-m> <sgp_> give me a sec
17:49:39 <br-m> <ofrnxmr:xmr.mx> Doubling every 2yrs, right?
17:49:51 <br-m> <sgp_> 985 MB BTC blocks at a 50% growth rate per year. 5.1 MB at 10% per year. 44.4 MB at 25% per year
17:49:53 <br-m> <articmine> Correct 
17:50:10 <br-m> <sgp_> 50%/year is more than doubling every 2
17:50:21 <br-m> <spackle> 2.25x but good enough for napkin math
17:50:36 <br-m> <articmine> Yes 1 GB at the end of this year I 
17:51:38 <br-m> <articmine> ... while the Bitcoin blocksize debate trust rages on 
17:52:51 <br-m> <sgp_> I'm not defending Bitcoin, but I think 44 MB would probably be enough for them as well :)
17:53:28 <br-m> <ofrnxmr:xmr.mx> Divide by 5 
17:53:57 <br-m> <articmine> By the way in 1979 I also got an error message when I tried to run a program that required 2 MB of RAM on the University of BC mainframe computer 
17:54:34 <br-m> <articmine> It was over the computer's maximum memory 
17:55:11 <br-m> <articmine> Technology changes but human nature does not 
17:56:54 <br-m> <spackle> I do not understand what is so incredibly magical about the surge factor of 16.
17:58:01 <br-m> <spackle> Surely some of that magic rubs off on 15? And a little makes its way to 12?
17:59:00 <br-m> <articmine> @spackle: This is not about a number. It is about.fear
17:59:59 <br-m> <articmine> @spackle: The fight will still happen at 12
18:00:14 <br-m> <spackle> Perhaps, so what? It is still exponential growth, with no change to the time base.
18:00:37 <br-m> <articmine> Going from 50 to 16 did not help 
18:01:05 <br-m> <spackle> The issue at hand is the gap between daemon performance and scaling design.
18:01:25 <br-m> <spackle> That change did not help, because it was not informed by that gap.
18:01:36 <br-m> <spackle> or rather, it did help but it did not address the issue.
18:01:39 <br-m> <articmine> @spackle: This is a short term issue that can be fixed
18:01:54 <br-m> <boog900> @articmine: its not.
18:01:58 <br-m> <articmine> The real issue is very different  
18:02:25 <br-m> <boog900> it will take a significant amount of time to get monerod efficient 
18:02:38 <br-m> <boog900> and we are very vulnerable num
18:02:38 <br-m> <sgp_> I personally don't like surge factors since I see surge = spam attack in my mind. I'm not specifically against 16+
18:03:16 <br-m> <articmine> @boog900: Well the sooner we start the process the better
18:03:34 <br-m> <boog900> why do we need 16?
18:03:39 <br-m> <articmine> Instead of arguing and trying to avoid it
18:03:45 <br-m> <boog900> you still haven't answered 
18:04:14 <br-m> <boog900> why not 50? 200? 8?
18:04:46 <br-m> <articmine> Here is my answer: To for CE a fix of a serious vulnerability 
18:05:01 <br-m> <articmine> Force a fix
18:05:20 <br-m> <boog900> what
18:05:42 <br-m> <articmine> If this is such an issue then the problem needs to be fixed 
18:06:28 <br-m> <boog900> no that is not an answer 
18:06:39 <br-m> <boog900> thats you being stubborn 
18:07:29 <br-m> <articmine> Sure it is. The only reason we are aware of this vulnerability is because of the stresstest
18:08:03 <br-m> <articmine> Which in part was provoked by the scaling algorithm 
18:08:38 <br-m> <boog900> we can make scaling more aggressive during tests 
18:08:52 <br-m> <boog900> they key being tests why risk monero for 16?
18:09:03 <br-m> <boog900> what makes it so important? 
18:09:50 <br-m> <articmine> No the real issue is why avoid fixed a serious problem 
18:10:22 <br-m> <boog900> listen. We can do both.
18:10:31 <br-m> <boog900> why do we need 16?
18:11:32 <br-m> <articmine> Why is 16 an issue 
18:11:54 <br-m> <boog900> because I think 32 MB blocks is too high for the short term 
18:12:06 <br-m> <boog900> monero currently breaks at 4MB FWIW 
18:12:36 <br-m> <spackle> mainnet would break at 1.5 MB without dynamic sync IIRC
18:12:44 <br-m> <articmine> I know which one is why we have to deal with this 
18:12:54 <br-m> <ofrnxmr:xmr.mx> @spackle: IBD, yeah
18:13:04 <br-m> <boog900> @articmine: I know 
18:13:36 <br-m> <ofrnxmr:xmr.mx> Monero also FULLY breaks at 25mb atm
18:13:37 <br-m> <boog900> but taking it down to 16 MB max would make it much more likely we can get monerod to match scaling in the short term 
18:13:42 <br-m> <ofrnxmr:xmr.mx> Due to serialization 
18:14:01 <br-m> <boog900> and I see no reason why this is an issue 
18:14:08 <br-m> <boog900> we have never has a surge this high 
18:14:21 <br-m> <boog900> and VISA self reports this number anyway 
18:14:56 <br-m> <jack_ma_blabla:matrix.org> @boog900: except spam attacks
18:15:19 <br-m> <articmine> @boog900: What happens if tomorrow there is a stat attack on VISA that takes VISA down
18:15:20 <br-m> <boog900> @jack_ma_blabla:matrix.org: even then we have never had a surge this high IIRC 
18:15:26 <br-m> <ofrnxmr:xmr.mx> vtnerd has a pr that has been opened for well over a year (8867 iirc) that addresses some or all of the serialization issues
18:15:42 <br-m> <articmine> Do you really think Monero will I be impacted 
18:16:16 <br-m> <ofrnxmr:xmr.mx> We've never had a competent spam attack, yet the sorry excuses have exposed issues (like causes nodes to crash (txrelay)
18:16:39 <br-m> <articmine> @ofrnxmr:xmr.mx: So why is this open for a year?
18:16:42 <br-m> <boog900> @articmine: why is this relevant? 
18:16:55 <br-m> <ofrnxmr:xmr.mx> @articmine: lack of review
18:17:38 <br-m> <ofrnxmr:xmr.mx> https://github.com/monero-project/monero/pull/8867
18:17:40 <br-m> <boog900> does a state taking down VISA make us surge 16x?
18:17:45 <br-m> <jack_ma_blabla:matrix.org> imho if there is a surge, users can pay higher fee & that will compensate miner penalty 
18:18:07 <br-m> <articmine> ... because if even a miniscule portion y the refugees end up on the Monero network we have a very serious vulnerability 
18:18:31 <br-m> <articmine> @boog900: Easily
18:18:34 <br-m> <boog900> @articmine: exactly. why 16x?
18:18:45 <br-m> <boog900> why not 32?
18:18:48 <br-m> <boog900> 64?
18:19:15 <br-m> <articmine> The higher the better 
18:19:44 <br-m> <boog900> monerod cannot handle infinite txs 
18:20:01 <br-m> <ofrnxmr:xmr.mx> > Unfortunately this diff is huge, and probably has no chance of ever being merged as-is. So I will try to break things into smaller chunks, with the caveat that if nobody wants the serialization to be replaced, its best to vote within this discussion thread here. > <@articmine> So why is this open for a year?
18:20:06 <br-m> <jack_ma_blabla:matrix.org> @articmine: are we living in a parrallel world ? xmr adoption is sloww [checks daily tx count for last couple of years] and no way we can see a overnight surge in demand, especially when there are no easy onramps
18:20:53 <br-m> <spackle> Of course we can see an overnight surge in demand, I don't think that is a good argument.
18:21:04 <br-m> <articmine> One legal reveal ad the on ramps are open 
18:21:13 <br-m> <articmine> Reversal 
18:21:24 <br-m> <articmine> Expect a flood 
18:21:25 <br-m> <jack_ma_blabla:matrix.org> @spackle: a overnight demand shouldnt mean we allow spam attacks
18:21:38 <br-m> <spackle> @jack_ma_blabla:matrix.org: agreed
18:22:04 <br-m> <articmine> We are not allowing spam attacks 
18:22:10 <br-m> <jack_ma_blabla:matrix.org> @articmine: see recent mined btc blocks
18:22:31 <br-m> <spackle> If there is a gap between daemon performance and scaling design in the short term, then yes we are allowing attacks.
18:23:34 <br-m> <jack_ma_blabla:matrix.org> @spackle: network constrains too 
18:24:50 <br-m> <articmine> What is clear is that we are simply not ready for FCMP++
18:25:05 <br-m> <spackle> That is not clear to me at all.
18:25:49 <br-m> <boog900> we are not ready for the next 4 hours 
18:26:21 <br-m> <boog900> FCMP is makes no difference and actually makes things better if we drop the amount we can grow blocks 
18:26:23 <br-m> <jack_ma_blabla:matrix.org> @articmine: thats why we work with what we have now and adapt later when daemon is capable of handling 'surge'
18:26:55 <nioc> seems that we are not ready for scaling beyond a certain point,  certainly we can handle txs that are 4x larger 
18:27:15 <nioc> today
18:27:36 <br-m> <ofrnxmr:xmr.mx> We can handle 4x larger txs, but not 100x larger blocks
18:28:50 <br-m> <articmine> We are way below 109
18:29:05 <br-m> <articmine> 100 x
18:29:32 <br-m> <ofrnxmr:xmr.mx> 100x is 30mb
18:29:34 <br-m> <articmine> I have heard like problems at 4 x
18:32:24 <br-m> <articmine> Keep in mind that ZCash survived a 300x spam attack 
18:33:02 <br-m> <articmine> We should be able to at least match them 
18:33:14 <br-m> <ofrnxmr:xmr.mx> Some of the issues fixed on stressnet but not mainnet:
18:33:14 <br-m> <ofrnxmr:xmr.mx> * 1.5mb blocks breaking IBD
18:33:14 <br-m> <ofrnxmr:xmr.mx> * txpool dying / pruning all txs
18:33:14 <br-m> <ofrnxmr:xmr.mx> * fluffyblocks not able to relay >4mb blocks[... more lines follow, see https://mrelay.p2pool.observer/e/wIyS_8MKV1phSWF2 ]
18:33:35 <br-m> <ofrnxmr:xmr.mx> @articmine: I think they benefit from not having a broken mempool
18:33:53 <br-m> <jack_ma_blabla:matrix.org> @articmine: so you want fcmp++ delayed till daemon code is optimized ? do we have resources? what would be eta?
18:34:11 <br-m> <articmine> We have some very serious issues 
18:34:36 <br-m> <articmine> @jack_ma_blabla:matrix.org: We raise the resources
18:35:04 <br-m> <boog900> why do we need to reach VISAs surge?
18:35:06 <br-m> <jack_ma_blabla:matrix.org> @articmine: where are these coders ? we have tried recruiting in past
18:35:23 <br-m> <boog900> like yeah we should process as many txs as possible 
18:35:38 <br-m> <boog900> but why this amount specifically 
18:35:49 <br-m> <jack_ma_blabla:matrix.org> someday mooon sun and regulations will align & a blackswan event will need xmr
18:35:52 <br-m> <articmine> Yes we have no choice but to delay until we at least can match ZCash 300x without breaking 
18:36:11 <br-m> <boog900> why delay we are vulnerable now 
18:36:28 <br-m> <boog900> more vulnerable now 
18:36:34 <br-m> <boog900> this is block size not tx
18:37:10 <br-m> <boog900> why with these arbitrary numbers from other systems too 
18:37:15 <br-m> <ofrnxmr:xmr.mx> Come from behind ia going to read this and fill mainnet txpool wirh 600mb of txs with fees at low tier :D 
18:37:46 <br-m> <ofrnxmr:xmr.mx> The majoriry of the txs will expire, cfb will get his money back, and xmr will be unusable 
18:37:49 <br-m> <boog900> I have though about making a count down till disaster website 
18:37:54 <br-m> <articmine> @ofrnxmr:xmr.mx: He doesn't have the money
18:38:23 <br-m> <ofrnxmr:xmr.mx> @articmine: He has enough mined xmr for 600mb of dust txa
18:38:40 <br-m> <jack_ma_blabla:matrix.org> @articmine: delay? eta? without a eta we cant delay it forever
18:38:43 <br-m> <jack_ma_blabla:matrix.org> @ofrnxmr:xmr.mx: or any zolder
18:38:45 <br-m> <jack_ma_blabla:matrix.org> @articmine: he has enough mined xmr to pay tx fees
18:39:23 <br-m> <ofrnxmr:xmr.mx> So while we all fuss about block sizes, we wont even make it that far
18:40:50 <br-m> <spackle> I'd prefer is we avoid abject pessimism, and stay solution oriented. There are steps that can would would be taken to handle any unexpected events.
18:41:14 <br-m> <ofrnxmr:xmr.mx> i dont think about these as unexpecred events 
18:41:21 <br-m> <spackle> The unfortunate thing is that steps would need to be taken.
18:41:22 <br-m> <ofrnxmr:xmr.mx> I wonder why nobody has done it
18:41:34 <br-m> <spackle> Fine, I phrased that poorly. Still, I hope you see my point.
18:42:19 <br-m> <ofrnxmr:xmr.mx> I see your point, but i think we need tk fix the immediate issues immediately 
18:42:31 <br-m> <jack_ma_blabla:matrix.org> @ofrnxmr:xmr.mx: now that this room is logged, it will be
18:43:04 <br-m> <ofrnxmr:xmr.mx> maybe that will incentivize us to fix things instead of leaving prs open for 4 yrs
18:43:58 <br-m> <ofrnxmr:xmr.mx> Its alwys better to be proactive than reactive 
18:44:25 <br-m> <ofrnxmr:xmr.mx> cfb's selfish mining exposed a few issues with our review process
18:44:39 <br-m> <ofrnxmr:xmr.mx> I think one thing i do that isnt often done, is actually test stuff
18:45:02 <br-m> <ofrnxmr:xmr.mx> There is a lot of code in monero that seems functionally correct, but doesnt actually work
18:45:10 <br-m> <ofrnxmr:xmr.mx> So i wonder how tf it got merged
18:45:25 <br-m> <0xfffc> Just do a master to release PR, to see how many useful PRs we have not merged to release 
18:46:43 <br-m> <ofrnxmr:xmr.mx> @ofrnxmr:xmr.mx: Thats not throwing shade at anyone, just amazes me sometimes how brittle monero is
18:47:51 <br-m> <0xfffc> @ofrnxmr:xmr.mx: Process is broken. Not fault of single person
18:48:23 <br-m> <ofrnxmr:xmr.mx> Like, blocks scale to infinity atm, but someone added hard limits on serialization and packet skzes
18:48:29 <br-m> <ofrnxmr:xmr.mx> So monero dies at 32 and 100mb 
18:48:56 <br-m> <ofrnxmr:xmr.mx> Its not technically possible to relay blocks larger atm
18:49:04 <br-m> <0xfffc> @ofrnxmr:xmr.mx:  check the DMs
18:49:10 <br-m> <ofrnxmr:xmr.mx> Someone added a 4mb limit to fluffy blocks
18:52:04 <nioc> posted 10 min ago  https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/621
18:52:22 <br-m> <spackle> The good news is that we have come a long way recently. Still, I know we would all sleep much better knowing that at least the next 50k blocks are covered. I don't see another clean target in the existing design, so I'll continue to hold that up as a standard.
18:53:22 <br-m> <spackle> Suppose I need to leave it here. Sorry to @boog900:monero.social  for my poor comment earlier, I did not realize how badly it read until after I sent it and I did not mean to imply what it did.
18:55:45 <br-m> <boog900> no need to say sorry I knew what you meant, it's not like I am doing the heavy lifting fixing monerod :D
18:56:01 <br-m> <boog900> I get the more fun job of rewriting it :) 
18:57:18 <br-m> <rucknium> @0xfffc: @0xfffc:monero.social: If the process is broken, then leadership needs to fix the process.
18:59:22 <br-m> <ofrnxmr> A lot of it is old fwiw
18:59:46 <br-m> <ofrnxmr> Like, untested prs with unaddressed comments -> merged
19:00:56 <br-m> <ofrnxmr> Currently the issue is manpower and duties. We have things that have been pending forever
20:12:06 <br-m> <articmine> @ofrnxmr:xmr.mx: Why!
20:13:20 <br-m> <ofrnxmr:xmr.mx> Idk
20:13:45 <br-m> <ofrnxmr:xmr.mx> I think it has probably been there since fluffyblocks was first introduced
20:14:15 <br-m> <ofrnxmr:xmr.mx> Jberman bumped it to 128mb on stressnet
20:14:52 <br-m> <boog900> tbf fluffy blocks should be 2 messages IMO
20:15:13 <br-m> <boog900> one for the block header notification one for the response to a request for missing txs
20:16:43 <br-m> <jberman> someone presumably thought that the daemon wouldn't ever need to relay the fluffy block txs, and just header
20:17:08 <br-m> <boog900> yep 
20:17:21 <br-m> <boog900> thats what the comment says 
20:19:28 <br-m> <boog900> the limits were added after the node DoS vulns around 2020 
20:21:30 <br-m> <articmine> Was the vulnerability fixed?
20:21:52 <br-m> <ofrnxmr> is this the dom dos?
20:22:54 <br-m> <boog900> there were multiple DoS vulns IIRC  
20:23:25 <br-m> <boog900> I don't know if this was a direct fix or just trying to make the system more resistant 
20:23:32 <br-m> <ofrnxmr> iiuc, 8867 (vtnerd) and 7999 (perfect daemon) both fixed the dom dos, but neither merged. There are hard limits in place instead (which essentially cap blocks to ~25mb)
20:27:25 <br-m> <articmine> ... and all the hard caps do is mitigate but not stop the DoS
20:31:43 <br-m> <articmine> Hence the "need" to cap the surge at 16 baking even more failure into the protocol 
20:33:40 <br-m> <articmine> Please understand why I have no choice but to take a very hard line on this 
20:38:50 <br-m> <boog900> @articmine: We can't do 16 MB blocks at the moment 
20:39:01 <br-m> <boog900> we need to make improvements to get there 
20:39:25 <br-m> <articmine> Can we do 8?
20:39:30 <br-m> <boog900> I think a 16 MB surge is more than enough and a good target to reach 
20:39:52 <br-m> <boog900> @articmine: no as we said earlier, I think someone mentioned 1.5 MB?
20:40:02 <br-m> <boog900> after that its 4 MB 
20:40:13 <br-m> <boog900> where the issues show^
20:41:39 <br-m> <articmine> I really have no choice here. I can't yield on scaling at all.
20:42:17 <br-m> <boog900> I mean thats fair it'll go to the vote
20:42:20 <br-m> <articmine> PR not being merged for years are solved with scaling parameters 
20:43:05 <br-m> <boog900> and there isn't a good reason shown for 16x other than just trying to push devs to work harder 
20:43:44 <br-m> <articmine> There are many reasons but the arguments are pointless 
20:44:17 <br-m> <boog900> @articmine: The PRs to get us beyond 16 MB aren't even thought out yet 
20:44:33 <br-m> <boog900> the current PRs wont get us to 32 MB comfortably 
20:44:45 <br-m> <articmine> If devs develop PR that is then not merged for years. 
20:45:20 <br-m> <articmine> This mess needs to be cleaned up first 
20:45:52 <br-m> <articmine> We should not even consider FCMP++
20:46:27 <br-m> <boog900> look we have already went over this 
20:46:39 <br-m> <articmine> Trying to hide the problem by preventing people from using Monero is not the answer 
20:46:54 <br-m> <boog900> 16 MB are more than enough!!!!
20:47:14 <br-m> <articmine> @boog900: That is no longer the point
20:47:22 <br-m> <boog900> trying to force devs to work by making monero vulnerable is also not the answer 
20:47:40 <br-m> <boog900> @articmine: it is the point
20:47:56 <br-m> <boog900> you are dying on the 32 MB hill just to be awkward 
20:48:33 <br-m> <articmine> It is a question of priorities. Basic security or the glamourous stuff 
20:49:24 <br-m> <boog900> No
20:49:29 <br-m> <boog900> we are vulnerable NOW
20:49:32 <br-m> <boog900> not with FCMP
20:49:36 <br-m> <articmine> I know 
20:49:51 <br-m> <boog900> it is Basic security and glamourous stuff OR VISA tx numbers
20:50:01 <br-m> <boog900> visa tx surge*
20:50:15 <br-m> <boog900> FCMP is unrelated this is block size 
20:51:23 <br-m> <articmine> 16 MB is like 15TPS Visa is like 9000 TPS
20:51:57 <br-m> <boog900> I corrected myself 
20:52:45 <br-m> <articmine> With ring CT at least we can do 60 TOS
20:52:52 <br-m> <articmine> TPS
20:53:38 <br-m> <boog900> anyway this is going no where, it'll go to the vote 
20:58:43 <br-m> <articmine> Fine
20:59:23 <br-m> <articmine> I am not going to be a party to what amounts to a coverup
21:08:03 <br-m> <articmine> I don't get it . People are saying we can't even do 1.5 MB and you are arguing between 16 MB and 32MB
21:08:47 <br-m> <boog900> I am trying to give us an easier target to hit, if you had a good reason for 32MB I would be more for looking at it 
21:09:04 <br-m> <boog900> but right now 32 MB is just targeting what VISA has reported as their surge 
21:09:18 <br-m> <boog900> it is not our surge, which you said is 2 to 3 x
21:10:19 <br-m> <articmine> I actually have a solution right now for 8 MB right now with Ring CT
21:10:36 <br-m> <articmine> But even that won't solve the problem 
21:10:37 <br-m> <boog900> go on ...
21:10:49 <br-m> <boog900> no it wont but still
21:11:44 <br-m> <articmine> Very simple implement my proposal with a 250000 bytes minimum penalty free zone 
21:12:20 <br-m> <articmine> Would work fine with our current RingCT
21:12:35 <br-m> <articmine> Yes it is a HF
21:12:37 <br-m> <boog900> oh I thought you were talking about getting the node to work with 8 MB blocks 
21:13:50 <br-m> <boog900> if we are changing scaling pre-FCMP I would rather it be a soft fork 
21:14:07 <br-m> <articmine> The 50000 block cap is 8 MB
21:14:31 <br-m> <articmine> Do it as a soft fork
21:15:38 <br-m> <articmine> I mean we are vulnerable now 
21:16:05 <br-m> <boog900> you can't change the penalty free zone in a soft fork 
21:16:53 <br-m> <articmine> True. Keep the penalty free zone and go to a 9600000
21:17:22 <br-m> <articmine> Block cap for 50000 blocks 
21:17:49 <br-m> <articmine> 9.6 MB
21:18:10 <br-m> <boog900> less than 32 MB?
21:19:01 <br-m> <articmine> With ring CT and the current penalty free zone it is 9.6 instead of 32
21:19:19 <br-m> <boog900> to reach VISA's surge?
21:19:24 <br-m> <articmine> Down from the current 30 MB
21:20:06 <br-m> <articmine> Yes we drop the surge from 50 to 16
21:20:33 <br-m> <articmine>  or the max from 100 to 32
21:20:38 <br-m> <boog900> why VISA's surge?
21:21:10 <br-m> <articmine> You are fixated on this 
21:21:50 <br-m> <boog900> 100% I want to know why we are basing our numbers on a different system 
21:22:11 <br-m> <boog900> I want to know what is so important about that you are unwilling to move 
21:22:26 <br-m> <articmine> We are basing on the patterns of commerce during the holidays 
21:23:00 <br-m> <articmine> It had to do with last minute shopping before a deadline 
21:23:01 <br-m> <boog900> which we have not seen
21:23:24 <br-m> <boog900> who is to say that number has not changed and will not change overtime
21:23:36 <br-m> <articmine> So we keep this at 50 instead 
21:23:57 <br-m> <articmine> and stay vulnerable 
21:42:34 <br-m> <boog900> I can't find the 20x claim anywhere  > <@articmine> We are basing on the patterns of commerce during the holidays 
21:43:10 <br-m> <boog900> we have this one: https://web.archive.org/web/20141108055312/https://www.visa.com/blogarchives/us/2011/01/12/visa-transactions-hit-peak-on-dec-23/index.html
21:44:05 <br-m> <boog900> which is 5.5x as far as I know 
21:44:31 <br-m> <boog900> with 11x as max capacity accordingly  
21:46:01 <br-m> <boog900> that is the busiest minute as well 
21:46:12 <br-m> <boog900> not sustained 
21:50:24 <br-m> <articmine> In 2010 Visa did around 1400 TPS average 
21:50:38 <br-m> <articmine> So about 17.4x
21:50:49 <br-m> <articmine> For the surge 
21:54:26 <br-m> <articmine> We must also keep in mind that a proprietary network has way more flexibility than a peer to peer decentralized currency 
21:55:23 <br-m> <articmine> So 16 with stiff pricing above makes optimal sense
21:57:21 <br-m> <boog900> @articmine: no thats to get to their capacity 
21:57:21 <br-m> <boog900> the holiday surge is ~7.8x
21:57:21 <br-m> <boog900> why are we trying reach their max capacity? 
21:57:39 <br-m> <boog900> @boog900: (if we use 1400, I have seen 2000)
21:58:07 <br-m> <articmine> They need a peak capacity over 17.4x over their average TPS 
21:58:44 <br-m> <boog900> yeah nice but we are talking about Monero 
21:59:03 <br-m> <boog900> We can have VISA's reported surge and stay at 16 MB!!!
21:59:30 <br-m> <articmine> 24000/1400 = 17.14
21:59:46 <br-m> <boog900> thats their capacity
21:59:49 <br-m> <articmine> It is the ratio that matters 
21:59:51 <br-m> <boog900> during a test
22:00:16 <br-m> <articmine> Between average and capacity 
22:00:32 <br-m> <boog900> why do we care how many txs VISA can process 
22:00:38 <br-m> <boog900> we are talking about peoples habits 
22:00:52 <br-m> <articmine> It is the ratio 
22:00:58 <br-m> <boog900> and how likely they are to spend more during the holiday 
22:01:27 <br-m> <articmine> The same for 1 TPS vs 10000 TPS
22:01:56 <br-m> <boog900> VISA said the chrsitamas peak was 11,000
22:02:11 <br-m> <boog900> during the busiest minute
22:02:32 <br-m> <boog900> You are being completely unreasonable 
22:02:38 <br-m> <boog900> I am done, it will go to vote 
22:02:41 <nioc> what is the likelihood that amazon or alibaba will start accepting monero?  and then that people will use it instead of getting 3-5% back using visa at amazon
22:03:20 <br-m> <articmine> People use Monero to buy gift cards
22:05:28 <br-m> <ofrnxmr> Our avg tps is 0.33 tho
22:08:41 <br-m> <321bob321> nioc: Black Friday sales ?
22:09:39 <br-m> <articmine>  Also Visa can increase capacity way faster than we can agree on a hard fork. 
22:09:39 <br-m> <articmine> This thread proves that. So we actually should have a bigger percentage margin that Visa
22:10:46 <br-m> <boog900> 8 > 7.8
22:11:12 <br-m> <boog900> also this is the busiest minute
22:12:33 <br-m> <boog900> nothing is going to convince you to change from 32 
22:14:05 <br-m> <sgp_> We wouldn't want someone to wait 2 blocks to get a confirmation in the busiest time of year, that's a complete failure of Monero. All peer to peer transactions will immediately migrate away from Monero and to ChainTRMtic Coin
22:14:54 <br-m> <sgp_> (I'm being dramatic but it does seem to be the type of foil applied, with only a slight exaggeration)
22:16:46 <br-m> <articmine> Card payments take 2-4 days to settle ve 20 min for XMR
22:17:27 <br-m> <ofrnxmr> 2 days to settle for xmr on a busy holiday isnt going to be end of the world imo
22:17:44 <br-m> <sgp_> So why do we need a burst allowance if it's ok to take 2 days to process the burst without a burst increase?
22:18:14 <br-m> <articmine> Who said 2.  days to settle XMR
22:18:41 <br-m> <articmine> I said 2-4 days for Visa
22:18:41 <br-m> <ofrnxmr> Im just saying that at 16mb, its not like we lose the txs. They just take a it longer to confirm
22:18:57 <br-m> <sgp_> I'm saying if because of a burst in demand, the backlog grows to 2 days. Without increasing the block size. But within 2 days later, the backlog/mempool is confirmed
22:19:31 <br-m> <articmine> You mean Bitcoin 
22:19:44 <br-m> <ofrnxmr> And i also suggested that we could add a 5th fee tier that is 10000x if we really want to grow beyond 16mb, because its not feasible to maintain those blocks for long
22:20:08 <br-m> <ofrnxmr> If we wamt to grow beyond 16mb in the short term*
22:20:18 <br-m> <articmine> 5 fee tiers are a good idea
22:21:13 <br-m> <articmine> 1 4  16; 64 256
22:22:05 <br-m> <sgp_> No. I mean suppose that blocks aren't full before black friday. But then bang, black friday happens. A huge mempool forms with 100x the normal capacity. It takes us 250 blocks to clear new transactions and the backlog fully.
22:22:06 <br-m> <sgp_> That's 8.3 hours, still way faster than a Visa "2-3 day" confirmation. So even with a 100x increase, do we need blocs to grow for a temporary burst? Even without the growth, Monero can win on speed
22:22:54 <br-m> <articmine> With your proposal it can easily take longer than Visa
22:23:07 <br-m> <articmine> Bitcoin 
22:23:25 <br-m> <articmine> Is an example 
22:24:15 <br-m> <sgp_> I'm not saying for my proposal, I'm saying even for your example with blocks that aren't full, why do we need the burst if we have 2 days of flexibility to confirm
22:25:22 <br-m> <articmine> People are complaining about 20 min
22:26:18 <br-m> <sgp_> yeah but it's you comparing the Visa processing capacity match. If you're cool with 2 days, then that suggests we don't need the burst?
22:26:39 <br-m> <sgp_> 2 days is 1,440 blocks, that's a lot
22:26:54 <br-m> <articmine> I am not cool with 2 days. I am a cash guy 
22:27:57 <br-m> <sgp_> new Monero L2 just dropped: cash! Withdraw XMR to cash once a month, use cash for p2p transactions. Scalability solved /s
22:29:21 <br-m> <sgp_> People can of course pay more to get in the next block if they can't wait the 2 days
22:30:09 <br-m> <sgp_> those who don't want to pay more go back into the "visa speed" lane temporarily, in a way. At least continuing your analogy
22:30:51 <br-m> <articmine> @sgp_: Bitcoin miners should accept XMR to accelerate BTC confirmations
22:31:29 <br-m> <sgp_> some already accept credit card for that, see mempool accelerator
22:32:38 <br-m> <articmine> I had a situation in 2018 where the miner only accepted BCH. No card and no XMR
22:33:27 <br-m> <articmine> It finally cleared the Bitcoin network a few hours later 
22:33:28 <br-m> <ofrnxmr> I mean, 2days is an exaggeration. 16mb blocks is 1.15m txs per day > <@articmine> I am not cool with 2 days. I am a cash guy 
22:33:32 <br-m> <sgp_> btc rbf has come a long way. They've committed to rbf
22:34:18 <br-m> <ofrnxmr> Rbf would be nice as well, but imo only if the tx parameters are the same. Essentially just a fee bump
22:34:54 <br-m> <sgp_> https://mrelay.p2pool.observer/m/monero.social/vmJGdKMrfbMNCynXjywtYOqY.png (image.png)
22:35:12 <br-m> <sgp_> 0.18 sats fit in the most recent block, wow. Very cheap txs currently
22:35:43 <br-m> <articmine> A double spend so that the miner takes the higher fee tx instead 
22:35:48 <br-m> <ofrnxmr> 16mb blocks is 11gb per day
22:35:55 <br-m> <ofrnxmr> The txpool is 600mb
22:36:07 <br-m> <articmine> Kills 0 confirmation transactions
22:36:29 <br-m> <ofrnxmr> @ofrnxmr: ^ artic
22:36:54 <br-m> <ofrnxmr> Meaning the tx would be the same tx just with a higher fee
22:37:13 <br-m> <sgp_> It does kill 0-conf by making the existing risks more pronounced. Whether that's a good or bad thing will depend on who you ask
22:37:34 <br-m> <articmine> @sgp_: Yes I know . Most of the economy has move to the banks so there is some room  on chain
22:37:37 <br-m> <sgp_> @ofrnxmr: that's not enforceable though right?
22:38:05 <br-m> <sgp_> miners don't need to care about the unconfirmed transaction and what it says
22:38:07 <br-m> <ofrnxmr> No idea
22:38:31 <br-m> <sgp_> you can ask miners "please don't do this" but they can ignore you
22:39:16 <br-m> <ofrnxmr> If a miner ran an alt implementation that accepted double spends, i guess? But normally it would treat it as a double spend if the tx was identical sans the fee
22:39:46 <br-m> <sgp_> miners have an incentive to take whatever tx has the higher fee and claim ignorance of the mempool one
22:39:47 <br-m> <articmine> Bitcoin is a broken system 
22:40:04 <br-m> <sgp_> @sgp_: this applies to Monero as well, today, fwiw
22:40:45 <br-m> <articmine> Yes it does apply to Monero, but the incentives are very different 
22:41:24 <br-m> <sgp_> I'd argue the anonymity offers a potentially greater incentive to try and fleece people, ha
22:42:49 <br-m> <articmine> @sgp_: I know that we disagree on this, but Blockchain Surveillance does not work on Bitcoin
22:43:30 <br-m> <articmine> There is more prii on Biti than people give it credit for 
22:43:39 <br-m> <articmine> Privacy 
22:44:48 <br-m> <sgp_> My main point it just that @ofrnxmr:monero.social your idea of preventing rbf except to the same recipient isn't enforceable unfortunately, for Bitcoin or for Monero
22:45:38 <br-m> <sgp_> rbf will be a potential risk even if normal nodes reject rbf
22:45:59 <br-m> <sgp_> which is one of the main arguments in favor of embracing rbf
22:47:43 <br-m> <ofrnxmr> Well, my initial purpose for rbf was to rbf invalid transactions
22:48:31 <br-m> <articmine> Online the merchant can wait. In person shoplifting or dine and dash are a much greater risk that an Rbf double spend with Monero 
22:49:39 <br-m> <sgp_> I tend to agree