<articmine> With respect to the transaction surge. We can cap the block instead of the short term median at 16x the long term median.

<articmine> That should provide the 50000 blocks runway, at 16x instead of 32x

<articmine> Still I feel that the Monero codebase is in a really poor state. This makes me very sad.

<articmine> 😂

<articmine> ZCash just flipped Monero. Frankly they deserve it given the sad state of the Monero codebase

<ofrnxmr:xmr.mx> Zcash hashrate has barely moved, and is still 70% on one pool

<ofrnxmr:xmr.mx> The "flippening" (imo) is more to do with cex availability + marketing + painting a chart. If it holds, it holds. Doge has a way higher market cap and almost nobody uses it on chain

<ofrnxmr:xmr.mx> Doge's codebase is absolute garbage

<ofrnxmr:xmr.mx> Meanwhile, we have a solid dev coming on board, and the proposal doesnt (yet. Its only a few hours old) have support BUT its already been attacked

<ofrnxmr:xmr.mx> repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/621

<ofrnxmr:xmr.mx> s/been/being

<spackle> The daemon is more capable than it has been allowed to be. It can and will handle the demands we are making of it, so long as we are thoughtful about those demands.

<spackle> While there is the appearance of disagreement, I don't think most people here are very different in their thinking. When talking about a lower surge factor, I don't actually think that there will be the same argument at lower and lower values. It just needs to be low enough to prevent the network from being ambushed, then that argument has been addressed.

<spackle> If there was development consensus that a surge factor of 8 was safe and someone proposed limiting it to 4, I would oppose that. I think many others would as well.

ofrnxmr any experienced dev would tell you that what they do is... questionable. They may be talented and capable, but the approach "this code is shit, let's rewrite everything" is not professional. Making PRs with thousands of changes all over the codebase is not the way to go. If they are able to make a lot of small PRs focusing on specific parts

of the code while working on this CCS, it will be a different story. But I somehow doubt it

Talking about repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/621

And I don't argue "this code is shit" part

<kayabanerve:matrix.org> I'm unsure where that proposal has already been attacked. I'd appreciate more description from it, personally

Plus we all remember the xz utils/jia tan story. Creating huge PRs with a lot of changes is the easiest way to backdoor the codebase. So no, I don't like their approach even if their intentions are pure.

<rbrunner7> @kayabanerve:matrix.org: This morning UTC somebody made around 4 or 5 accounts and posted nonsense comments for that "anon" CCS PR, and made nonsense downvotes with them. That's all already cleaned up, hence your head-scratching :)

<rbrunner7> All seemingly against it, of course, with poo emojis and all

<rbrunner7> A really brutal attack

<kayabanerve:matrix.org> Ah. That sucks

<kayabanerve:matrix.org> I don't personally like perfect-daemon based on past abrasiveness, but their rate is reasonable if they can and want to be a team player. I appreciate the CCS as the first step and would hope for a bit more detail to justify the CCS itself.

<kayabanerve:matrix.org> Maybe, instead of the bureaucracy of spelled out milestones, they could offer a commitment to work with @jberman:monero.social: so the oversight occurs that way?

<kayabanerve:matrix.org> (I believe they got along)

<kayabanerve:matrix.org> sech1: Not immediately related, but I wrote a comprehensive JSON library without dependency for Rust, and there's a PR to oxide to own the Ed25519 API so we can arbitrarily upgrade its internals. The RPC code also is entirely abstract to the transport, so no HTTP/TLS client is embedded.

<kayabanerve:matrix.org> TL;DR oxide is undergoing writes but I'm working on reducing the supply chain risk and total scope.

nice

<kayabanerve:matrix.org> Also, of course, Monero will only use a fraction and won't have any Rust JSON code

<monero.arbo:matrix.org> the question is one of "acceptable" risk. Which actually fits in rather well to how PoW works in general. In person $40 transaction? Probably fine at 0-conf. $200? Maybe wait for a confirmation or two. $2,000? you might wanna wait the full 10 blocks. > <@sgp_> rbf will be a potential risk even if normal nodes reject rbf

<kayabanerve:matrix.org> I think one should always wait until presumed finality, and we must disavow any usecases suggesting otherwise to be clear it's at the user's risk

<monero.arbo:matrix.org> The point is PoW finality is always probabilistic and if anything users should be educated to that fact and not think something is final just because it has an arbitrary number of confirmations

<monero.arbo:matrix.org> we know from recent experience after all that re-orgs significantly deeper than 10 blocks are quite possible. But it doesn't really make sense to ask users to "always" wait for half an hour, an hour, or whatever we decide seems "safe enough"

<monero.arbo:matrix.org> if by "presumed finality" you mean when the value of the transaction is less than the cost of double spending it, I agree, but I think that still leaves room for 0-conf to be viable in a lot of situations

<spirobel:kernal.eu> @kayabanerve:matrix.org: maybe we could introduce a counter that calculates how much money was spent on electricity since the transaction landed in a block. that would give people an intuition

<hooftly:matrix.org> But arent electricty costs vastly different per region?

<spirobel:kernal.eu> @hooftly:matrix.org: yes. its not perfect

<spirobel:kernal.eu> just some estimate to convey the vibe. best we can do to give an honest idea for finality in pow

<articmine> @spirobel:kernal.eu: It would have to be the amount of electricity rather than its cost.

<articmine> Denominated in kWh.

<ofrnxmr:xmr.mx> How do we know how much power is used? Kw per hash isnt static

<articmine> One of the biggest myths around POW is ignoring the value or cost of disposal of the heat produced and ignoring the physics of the first law of thermodynamics

<articmine> @ofrnxmr:xmr.mx: You don't. All one hope for is some kind of estimated average

<sgp_> Just do it based on the block reward. $X in reward is roughly equal to $Y in mining cost

<sgp_> You are receiving 10 XMR? Wait 17 blocks I guess

so, why is the block growth exponential instead of logarithmic?

logarithmic would end up with your "hard spring" at the end

<kayabanerve:matrix.org> @spirobel:kernal.eu: @sgp_:monero.social: What if 1000 TXs for 1 XMR are sent to 1000 merchants, for 1000 small double-spends effecting one large profit gain? The lack of ability to view network-wide turnover makes that ineffective.

<sgp_> I'm not going to argue with you since I support the finality layer, ha

<spirobel:kernal.eu> @kayabanerve:matrix.org: true its not perfect. but its actually a good suggestion. seems straight forward and understandable: This much block reward was paid to miners since you received this transaction

<spirobel:kernal.eu> we can just call it: security fee paid by the network since inclusion

<spirobel:kernal.eu> its not perfect, but thats exactly the point. There are limits to how good the current system is

<spirobel:kernal.eu> once we have that out of the way we can have a reasonable non emotion based discussion about how to improve it

<kayabanerve:matrix.org> @sgp_: PoW brokies unable to refute facts and logic /s

<sgp_> I only credit the XMR I receive after the block is added to the list of hardcored checkpoints in monerod

<kayabanerve:matrix.org> Literally a finalization layer

<spirobel:kernal.eu> @kayabanerve:matrix.org: kaya owning the powtards with facts and logic. Maybe we can use ai to turn this into a youtube show

<spirobel:kernal.eu> would be a banger