04:10:45 With respect to the transaction surge. We can cap the block instead of the short term median at 16x the long term median. 04:10:45 That should provide the 50000 blocks runway, at 16x instead of 32x 04:10:45 Still I feel that the Monero codebase is in a really poor state. This makes me very sad. 04:11:05 😂 04:24:31 ZCash just flipped Monero. Frankly they deserve it given the sad state of the Monero codebase 04:44:41 Zcash hashrate has barely moved, and is still 70% on one pool 04:44:41 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 04:44:51 Doge's codebase is absolute garbage 04:47:28 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 04:47:29 https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/621 04:49:50 s/been/being 05:33:09 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. 06:52:36 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. 06:54:09 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. 08:19:30 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 08:19:30 of the code while working on this CCS, it will be a different story. But I somehow doubt it 08:19:42 Talking about https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/621 08:20:16 And I don't argue "this code is shit" part 09:21:43 I'm unsure where that proposal has already been attacked. I'd appreciate more description from it, personally 09:57:57 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. 11:02:42 @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 :) 11:04:01 All seemingly against it, of course, with poo emojis and all 11:04:19 A really brutal attack 11:09:00 Ah. That sucks 11:10:02 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. 11:10:36 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? 11:10:38 (I believe they got along) 11:13:42 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. 11:16:21 TL;DR oxide is undergoing writes but I'm working on reducing the supply chain risk and total scope. 11:16:31 nice 11:16:54 Also, of course, Monero will only use a fraction and won't have any Rust JSON code 11:53:40 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 12:27:08 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 12:28:57 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 12:30:39 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" 12:40:58 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 13:49:26 @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 13:50:57 But arent electricty costs vastly different per region? 13:55:19 @hooftly:matrix.org: yes. its not perfect 13:56:17 just some estimate to convey the vibe. best we can do to give an honest idea for finality in pow 14:23:12 @spirobel:kernal.eu: It would have to be the amount of electricity rather than its cost. 14:23:44 Denominated in kWh. 14:26:03 How do we know how much power is used? Kw per hash isnt static 14:26:34 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 14:31:21 @ofrnxmr:xmr.mx: You don't. All one hope for is some kind of estimated average 16:27:17 Just do it based on the block reward. $X in reward is roughly equal to $Y in mining cost 16:28:10 You are receiving 10 XMR? Wait 17 blocks I guess 20:43:39 so, why is the block growth exponential instead of logarithmic? 20:43:58 logarithmic would end up with your "hard spring" at the end 21:57:22 @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. 21:58:37 I'm not going to argue with you since I support the finality layer, ha 21:59:22 @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 21:59:53 we can just call it: security fee paid by the network since inclusion 22:00:17 its not perfect, but thats exactly the point. There are limits to how good the current system is 22:00:39 once we have that out of the way we can have a reasonable non emotion based discussion about how to improve it 22:01:28 @sgp_: PoW brokies unable to refute facts and logic /s 22:02:47 I only credit the XMR I receive after the block is added to the list of hardcored checkpoints in monerod 22:17:15 Literally a finalization layer 22:22:50 @kayabanerve:matrix.org: kaya owning the powtards with facts and logic. Maybe we can use ai to turn this into a youtube show 22:22:57 would be a banger