06:02:25 <m-relay> <r​brunner7:monero.social> kayabanerve: My estimate that we could, by throwing most dev capacity into it, hardfork to Seraphis end of next year or early 2026, was assuming *without* FCMP. But hey, after reading the sentiment here, I don't think that *any* such estimates still matter. If, for me surprisingly, your proposal for "FCMPs for RingCT" works on a technical level, there will be a stampede into it no matter what.
06:05:41 <m-relay> <r​brunner7:monero.social> I really am still in awe how incredibly few resources it needed to change the course of the Monero project. I never saw such a nice, gentle and friendly spammer like the one that spammed our blockchain for 3 weeks, but it seems what they did is all that was needed to already shake confidence. Let's see where this will lead us.
06:07:08 <sech1> Right now someone is doing a lot of 146/2 transactions (consolidations)
06:07:12 <sech1> blocks are full again
06:08:09 <m-relay> <r​brunner7:monero.social> And everthing works nicely, right?
06:08:19 <m-relay> <r​brunner7:monero.social> As designed, and as it should
06:09:03 <sech1> yes
07:08:26 <sech1> I counted around 150 transactions of 146/2...151/2 type, so it's around 22000 outputs being consolidated. Can it be the spammer consolidating outputs they used for the spam before?
07:21:02 <dukenukem> -14
11:04:42 <m-relay> <o​ne-horse-wagon:monero.social> Artic Mine.  With your very high bandwidth that you have, how many "in" computers typically attach to your node?  The highest I ever get on my nodes is 150 or so.
13:47:42 <m-relay> <r​avfx:xmr.mx> That's is with a 2GB symmetrical fiber
13:47:42 <m-relay> <r​avfx:xmr.mx> it usually hover slightly over that 150 mark, but not by much
13:47:51 <m-relay> <r​avfx:xmr.mx> https://matrix.monero.social/_matrix/media/v1/download/xmr.mx/lfzIJnCtmcMLbAumofaAsPLC
15:20:28 <m-relay> <k​ayabanerve:matrix.org> ArticMine: I believe it's (10+(2*11)+10+(2*10))*32 + (7*32) bytes an input. ~2.2kB. I'd round up to 2.5.
15:20:28 <m-relay> <k​ayabanerve:matrix.org> This replaces CLSAG.
15:20:29 <m-relay> <k​ayabanerve:matrix.org> And also, apologies for starting my earlier message with "No, " when you were correct to the most recent message at the time. I had yet to publicize my improvements then.
20:33:19 <m-relay> <a​rticmine:monero.social> Thank you. This is very helpful. I get 2208 bytes an input. 
20:33:20 <m-relay> <a​rticmine:monero.social> Total transaction weight for 2/2 in the 5000 bytes to 6000 bytes range. I will go with a 600000 byte minimum penalty free zone. This is 2x the current value. This will of course support further optimizations for example with Seraphis. 
20:33:20 <m-relay> <a​rticmine:monero.social> As for fees we are looking at 5x to 6x the current minimum fee for the new minimum fee in terms of XMR. This is due to moving from 1% to 2% growth in the short term median (4x) and a further up to 1.5x due to the larger ratio of the transaction weight to the minimum penalty free zone
20:34:09 <m-relay> <a​rticmine:monero.social> No need to apologize.
20:43:15 <m-relay> <a​rticmine:monero.social> Theoretically this FCMP or a 64 ring CLSAG could be supported with a 1% growth rate for the short term median (6000 byte reference transaction weight) but it would be very tight. It should work very well with a 2% growth rate for the short term median (12000 byte reference transaction weight).
20:50:34 <m-relay> <a​rticmine:monero.social> On another note this also keeps the option of lowering the fees 4x in the future without a hard fork especially if there are further optimizations.
21:16:56 <m-relay> <a​rticmine:monero.social> I had to take my open nodes off line due to renovations at my house. So I don't have recent results. 
21:16:57 <m-relay> <a​rticmine:monero.social> The figure of around 150 in connections is about what I have seen historically. I mean at least back to 2017. What I do remember is around 150 in connections back in 2017 - 2018 over a 2Mbps ADSL connection. The math for this does make sense. 300000 bytes every 2 min sent out at a rate of 24x works out to 480Kbps. That is equivalent to supportting 144 nodes with each node taking 1<clipped messag
21:16:57 <m-relay> <a​rticmine:monero.social> /12 of their data from the node and receiving relayed transactions and mined blocks.
21:21:26 <m-relay> <a​rticmine:monero.social> If one can isolate the node monitoring the upload bandwidth and   comparing this with the number of in put connections and average block size one can verify the above. 
21:21:26 <m-relay> <a​rticmine:monero.social> I am going to set up this test.