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

<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.

<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 mrelay.p2pool.observer/e/nZf46cMKbEF3T0U2 ]

<ofrnxmr> what makes you say half a day?

<ofrnxmr> If prepared, i think a 600mb txpool is bad enough

<ofrnxmr> So more like, however long it takes to spam that many txs

<ofrnxmr> But thats not necessarily a scaling problem, just poorly designed.

<ofrnxmr> are you referring to block growth over 12hrs?

<spackle> I gave that estimate in the interest of making my point while also being generous.

<ofrnxmr> but what is the estimate referring to, block growth?

<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.

<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)

<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.

<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.

<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

<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

<ofrnxmr> Which would allow scaling to be slowed down a bit w/o dropping txs

<articmine> Technically to max out the proposed cap on the short term median one needs 32 MB, assuming a 1 MB penalty free zone

<articmine> This provides over 2 months

<articmine> 50000 blocks to be exact

<321bob321> signal.org/blog/spqr

<321bob321> Signal Protocol and Post-Quantum Ratchets

<spackle> @articmine: If this is the network stability target it should be an acknowledged performance requirement by developers (jberman and jeffro specifically).

<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.

<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.