📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 7, 2015 at 6:11 PM, Mike Hearn <mike at plan99.net> wrote:
>> It is an argument against my admittedly vague definition of
>> "non-controversial change".
>
>
> If it's an argument against something you said, it's not a straw man, right
> ;)
Yes, but it was an argument against something I didn't said ;)
> Consensus has to be defined as agreement between a group of people. Who are
> those people? If you don't know, it's impossible to decide when there is
> consensus or not.
>
> Right now there is this nice warm fuzzy notion that decisions in Bitcoin
> Core are made by consensus. "Controversial" changes are avoided. I am trying
> to show you that this is just marketing. Nobody can define what these terms
> even mean. It would be more accurate to say decisions are vetoed by whoever
> shows up and complains enough, regardless of technical merit.
Yes, that's why I drafted a definition for "uncontroversial change"
rather than "change accepted by consensus".
It will still be vague and hard to define, but consensus seems much harder.
And, yes, you're right, it is more like giving power to anyone with
valid arguments to veto hardfork changes.
But as you say, that could lead to make hardforks actually impossible,
so we should limit what constitutes a valid argument.
I later listed some examples of invalid arguments: logical fallacies,
unrelated arguments, outright lies.
Certainly I don't think technical merits should count here or that we
could veto a particular person from vetoing.
We should filter the arguments, not require an identity layer to
blacklist individuals.
We should even accept arguments from anonymous people in the internet
(you know, it wouldn't be the first time).
> Unfortunately it's hard to know what other kinds of meet-in-the-middle
> compromise could be made here. I'm sure Gavin would consider them if he
> knew. But the concerns provided are too vague to address. There are no
> numbers in them, for example:
>
> We need more research -> how much more?
Some research at all about fee market dynamics with limited size that
hasn't happened at all.
If we're increasing the consensus max size maybe we could at least
maintain the 1MB limit as a standard policy limit, so that we can
study it a little bit (like we could have done instead of removing the
initial policy limit).
> I'm not against changing the size, just not now -> then when?
I don't know yet, but I understand now that having a clearer roadmap
is what's actually urgent, not the change itself.
> I'm not wedded to 1mb, but not sure 20mb is right -> then what?
What about 2 MB consensus limit and 1 MB policy limit for now? I know
that's arbitrary too.
> Full node count is going down -> then what size do you think would fix that?
> 100kb?
As others have explained, the number of full nodes is not the
improtant part, but how easy it is to run one.
I think a modest laptop with the average internet connection of say,
India or Brazil, should be able to run a full node.
I haven't made those numbers myself but I'm sure that's possible with
1 MB blocks today, and probably with 2 MB blocks too.
> It will make mining more centralised -> how do you measure that and how much
> centralisation would you accept?
This is an excellent question for both sides.
Unfortunately I don't know the answer to this. Do you?
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 15:33:25
in reply to nevent1q…n8x4
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 15:33:25Event JSON
{
"id": "c97cd3f4c04b971475446b6c22fc48435eb55bced29deac3c5266a2de6250db0",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686152005,
"kind": 1,
"tags": [
[
"e",
"0def597b074aa190bf159e12f9433ea74d157ee52321b38d195ba644ad5c177f",
"",
"root"
],
[
"e",
"ad4837e425545bf4ea14fce938d911633475a391a11a14a97cd7bf76129774f0",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2015-05-07\n📝 Original message:On Thu, May 7, 2015 at 6:11 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e\u003e It is an argument against my admittedly vague definition of\n\u003e\u003e \"non-controversial change\".\n\u003e\n\u003e\n\u003e If it's an argument against something you said, it's not a straw man, right\n\u003e ;)\n\nYes, but it was an argument against something I didn't said ;)\n\n\u003e Consensus has to be defined as agreement between a group of people. Who are\n\u003e those people? If you don't know, it's impossible to decide when there is\n\u003e consensus or not.\n\u003e\n\u003e Right now there is this nice warm fuzzy notion that decisions in Bitcoin\n\u003e Core are made by consensus. \"Controversial\" changes are avoided. I am trying\n\u003e to show you that this is just marketing. Nobody can define what these terms\n\u003e even mean. It would be more accurate to say decisions are vetoed by whoever\n\u003e shows up and complains enough, regardless of technical merit.\n\nYes, that's why I drafted a definition for \"uncontroversial change\"\nrather than \"change accepted by consensus\".\nIt will still be vague and hard to define, but consensus seems much harder.\nAnd, yes, you're right, it is more like giving power to anyone with\nvalid arguments to veto hardfork changes.\nBut as you say, that could lead to make hardforks actually impossible,\nso we should limit what constitutes a valid argument.\nI later listed some examples of invalid arguments: logical fallacies,\nunrelated arguments, outright lies.\nCertainly I don't think technical merits should count here or that we\ncould veto a particular person from vetoing.\nWe should filter the arguments, not require an identity layer to\nblacklist individuals.\nWe should even accept arguments from anonymous people in the internet\n(you know, it wouldn't be the first time).\n\n\u003e Unfortunately it's hard to know what other kinds of meet-in-the-middle\n\u003e compromise could be made here. I'm sure Gavin would consider them if he\n\u003e knew. But the concerns provided are too vague to address. There are no\n\u003e numbers in them, for example:\n\u003e\n\u003e We need more research -\u003e how much more?\n\nSome research at all about fee market dynamics with limited size that\nhasn't happened at all.\nIf we're increasing the consensus max size maybe we could at least\nmaintain the 1MB limit as a standard policy limit, so that we can\nstudy it a little bit (like we could have done instead of removing the\ninitial policy limit).\n\n\u003e I'm not against changing the size, just not now -\u003e then when?\n\nI don't know yet, but I understand now that having a clearer roadmap\nis what's actually urgent, not the change itself.\n\n\u003e I'm not wedded to 1mb, but not sure 20mb is right -\u003e then what?\n\nWhat about 2 MB consensus limit and 1 MB policy limit for now? I know\nthat's arbitrary too.\n\n\u003e Full node count is going down -\u003e then what size do you think would fix that?\n\u003e 100kb?\n\nAs others have explained, the number of full nodes is not the\nimprotant part, but how easy it is to run one.\nI think a modest laptop with the average internet connection of say,\nIndia or Brazil, should be able to run a full node.\nI haven't made those numbers myself but I'm sure that's possible with\n1 MB blocks today, and probably with 2 MB blocks too.\n\n\u003e It will make mining more centralised -\u003e how do you measure that and how much\n\u003e centralisation would you accept?\n\nThis is an excellent question for both sides.\nUnfortunately I don't know the answer to this. Do you?",
"sig": "823d3e4626f168267a2352a44466828c3d8a8676fdc16e2bfd50c3b0bd25bdd5b5d59c5195a52ee19b7d50088f2e65e17a902a5df7a78a566a2b28629bcfd184"
}