And the answer would be: no
Sufficient trust in a mint would be centralization. This applies even to trust in several large mints.
I agree with your second point and Monerans have been avoiding my query on this, but i disagree with your first point about frequent hard forks. It's "how" it's done that is important, not how often. The HF's that take place are years in the making, focused on improving the single value proposition for XMR. They go through rigourous testing by skilled devs. The community can reject it, but rarely do because, and it bares repeating, they only have one goal. Privacy. No ETF's or corporate/state actors to appease, no mining conglomerates or electricity infra, no layer 2 scaling or smart contracts to integrate, no ordinals or Script externalities like BitVm.
This means only a handful of experts need to work on a given fork, itself trying to fix a potential problem, push the fix and move on with their lives, like with RandomX. Whereas with other projects you need to pass on the torch, audit Interoperability, and consult with veterans and stake holders.
Scheduled Hard forks in Monero are way less dramatic than in politics based Bitcoin and even less than in centralized upgrades like Windows going from one version to another.
Monero is so simple, it eliminates entire classes of issues that would make frequent hard forks "scary", whereas Bitcoin preserves old problems to keep legacy devs employed.
Cyber Seagull
npub1w7…mwyhg
2024-05-14 14:19:00
in reply to nevent1q…kluk
Author Public Key
npub1w72nkwnrhncuwjxmmmh3px74dhjgcv8de5nayzfygrp6mj33e96sumwyhgPublished at
2024-05-14 14:19:00Event JSON
{
"id": "4f78c262e382da1b76d1bab098a258d1235ea2861de9bdd4e4f927871851d5b1",
"pubkey": "77953b3a63bcf1c748dbdeef109bd56de48c30edcd27d2092440c3adca31c975",
"created_at": 1715696340,
"kind": 1,
"tags": [
[
"e",
"c19a04627cb6354fcf65fe0cc38b3023fd877af3363e27e7841e1fc0b2fc1a9d",
"",
"root"
],
[
"e",
"1009186b4a2dbf5c07b55e7ec608e16ad3978acff6d5a4f7ac112aa8ac123cf8"
],
[
"e",
"eb42e5a147afba3c075473bd2174c909ea30ab290cd38c9f4fdf312f372c3498",
"",
"reply"
],
[
"p",
"d91191e30e00444b942c0e82cad470b32af171764c2275bee0bd99377efd4075"
],
[
"p",
"c6787c844d9c254bef5cb96d45c677528742cb4d5e0d224eeed8edd93c0a97ce"
],
[
"p",
"d91191e30e00444b942c0e82cad470b32af171764c2275bee0bd99377efd4075"
],
[
"p",
"83d302b5c25ed43e5b75532fa6a6bda21c4b63e9f516826798f516fc4159b9c7"
],
[
"p",
"c5273075de02a2beedad450ff60f0d47c67f28a2299fb804611d3ee5219df5f4"
],
[
"p",
"77953b3a63bcf1c748dbdeef109bd56de48c30edcd27d2092440c3adca31c975"
]
],
"content": "And the answer would be: no\n\nSufficient trust in a mint would be centralization. This applies even to trust in several large mints. \n\nI agree with your second point and Monerans have been avoiding my query on this, but i disagree with your first point about frequent hard forks. It's \"how\" it's done that is important, not how often. The HF's that take place are years in the making, focused on improving the single value proposition for XMR. They go through rigourous testing by skilled devs. The community can reject it, but rarely do because, and it bares repeating, they only have one goal. Privacy. No ETF's or corporate/state actors to appease, no mining conglomerates or electricity infra, no layer 2 scaling or smart contracts to integrate, no ordinals or Script externalities like BitVm. \n\nThis means only a handful of experts need to work on a given fork, itself trying to fix a potential problem, push the fix and move on with their lives, like with RandomX. Whereas with other projects you need to pass on the torch, audit Interoperability, and consult with veterans and stake holders.\n\nScheduled Hard forks in Monero are way less dramatic than in politics based Bitcoin and even less than in centralized upgrades like Windows going from one version to another.\n\nMonero is so simple, it eliminates entire classes of issues that would make frequent hard forks \"scary\", whereas Bitcoin preserves old problems to keep legacy devs employed.\n",
"sig": "d75c2bf92a47f0d39e359bcb064907f2648fb14c250011c9a7815e3b9a6542fbcfc63ddc722bddf44d50e3d82e887ad0c1a1b16b2adda14c7e76868c9b456485"
}