📅 Original date posted:2015-05-07
📝 Original message:Replies inline.
On 05/07/15 17:43, Mike Hearn wrote:
> The only answer to this that anyone with a clue should give is "it
> will very, very likely be able to support at least 1MB blocks
> roughly every 10 minutes on average for the next eleven years, and
> it seems likely that a block size increase of some form will happen
> at some point in the next eleven years", anything else is dishonest.
>
>
> Matt, you know better than that. Gavin neither lacks clue nor is he
> dishonest.
No, I dont think Gavin is being deliberately dishonest, and I'm rather
confident he phrased everything in a way that is technically true (ie
the quote in his response). However, others have definitely not taken
away the correct interpretation of what he said, and this is a serious
problem. Setting expectations correctly as this is a very contentious
issue and one that does not appear to be reaching consensus quickly in
the technical community is important.
More generally, consider the situation we're in now. Gavin is going off
pitching this idea to the general public (which, I agree, is an
important step in pulling off a hardfork) while people who actually
study the issues are left wondering why they're being ignored (ie why is
there no consensus-building happening on this list?).
> He has been working on the assumption that other developers are
> reasonable, and some kind of compromise solution can be found that
> everyone can live with. Hence trying to find a middle ground, hence
> considering and writing articles in response to every single objection
> raised. Hence asking for suggestions on what to change about the plan,
> to make it more acceptable. What more do you want, exactly?
The appropriate method of doing any fork, that we seem to have been
following for a long time, is to get consensus here and on IRC and on
github and *then* go pitch to the general public (either directly or by
releasing software) that they should upgrade. I admit that hardforks are
a bit different in that the level of software upgrade required means
additional lead time, but I'm not sure that means starting the
public-pitching phase before there is any kind of consensus forming
(actually, I'd point out that to me there seems to be rahter clear
consensus outside of you and Gavin that we should delay increasing block
size).
As far as I can tell, there has been no discussion of block sizes on
this list since 2013, and while I know Gavin has had many private
conversations with people in this community about the block size, very
little if any of it has happened in public.
If, instead, there had been an intro on the list as "I think we should
do the blocksize increase soon, what do people think?", the response
could likely have focused much more around creating a specific list of
things we should do before we (the technical community) think we are
prepared for a blocksize increase.
> And I'll ask again. Do you have a *specific, credible alternative*?
> Because so far I'm not seeing one.
A specific credible alternative to what? Committing to blocksize
increases tomorrow? Yes, doing more research into this and developing
software around supporting larger block sizes so people feel comfortable
doing it in six months. I acknowledge that Gavin has been putting a lot
of effort into this front, but, judging by this thread, I am far from
the only one who thinks much more needs done.
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-07 15:33:22
in reply to nevent1q…w25w
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-07 15:33:22Event JSON
{
"id": "84e6560261816b4cb8deee69c24d8b0b5158d5bfb686642216b7c1f132853f1a",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686152002,
"kind": 1,
"tags": [
[
"e",
"0def597b074aa190bf159e12f9433ea74d157ee52321b38d195ba644ad5c177f",
"",
"root"
],
[
"e",
"b1268bcae32de9e39ef6bef8edda0e6307abc4f3a2a7acc9717768fe90eaec9f",
"",
"reply"
],
[
"p",
"787ecd48da0d9610d322fb67c86ad23a5287d688559b2ff8ee546721fd990129"
]
],
"content": "📅 Original date posted:2015-05-07\n📝 Original message:Replies inline.\n\nOn 05/07/15 17:43, Mike Hearn wrote:\n\u003e The only answer to this that anyone with a clue should give is \"it\n\u003e will very, very likely be able to support at least 1MB blocks\n\u003e roughly every 10 minutes on average for the next eleven years, and\n\u003e it seems likely that a block size increase of some form will happen\n\u003e at some point in the next eleven years\", anything else is dishonest.\n\u003e \n\u003e \n\u003e Matt, you know better than that. Gavin neither lacks clue nor is he\n\u003e dishonest. \n\nNo, I dont think Gavin is being deliberately dishonest, and I'm rather\nconfident he phrased everything in a way that is technically true (ie\nthe quote in his response). However, others have definitely not taken\naway the correct interpretation of what he said, and this is a serious\nproblem. Setting expectations correctly as this is a very contentious\nissue and one that does not appear to be reaching consensus quickly in\nthe technical community is important.\nMore generally, consider the situation we're in now. Gavin is going off\npitching this idea to the general public (which, I agree, is an\nimportant step in pulling off a hardfork) while people who actually\nstudy the issues are left wondering why they're being ignored (ie why is\nthere no consensus-building happening on this list?).\n\n\n\u003e He has been working on the assumption that other developers are\n\u003e reasonable, and some kind of compromise solution can be found that\n\u003e everyone can live with. Hence trying to find a middle ground, hence\n\u003e considering and writing articles in response to every single objection\n\u003e raised. Hence asking for suggestions on what to change about the plan,\n\u003e to make it more acceptable. What more do you want, exactly?\n\nThe appropriate method of doing any fork, that we seem to have been\nfollowing for a long time, is to get consensus here and on IRC and on\ngithub and *then* go pitch to the general public (either directly or by\nreleasing software) that they should upgrade. I admit that hardforks are\na bit different in that the level of software upgrade required means\nadditional lead time, but I'm not sure that means starting the\npublic-pitching phase before there is any kind of consensus forming\n(actually, I'd point out that to me there seems to be rahter clear\nconsensus outside of you and Gavin that we should delay increasing block\nsize).\nAs far as I can tell, there has been no discussion of block sizes on\nthis list since 2013, and while I know Gavin has had many private\nconversations with people in this community about the block size, very\nlittle if any of it has happened in public.\nIf, instead, there had been an intro on the list as \"I think we should\ndo the blocksize increase soon, what do people think?\", the response\ncould likely have focused much more around creating a specific list of\nthings we should do before we (the technical community) think we are\nprepared for a blocksize increase.\n\n\u003e And I'll ask again. Do you have a *specific, credible alternative*?\n\u003e Because so far I'm not seeing one.\n\nA specific credible alternative to what? Committing to blocksize\nincreases tomorrow? Yes, doing more research into this and developing\nsoftware around supporting larger block sizes so people feel comfortable\ndoing it in six months. I acknowledge that Gavin has been putting a lot\nof effort into this front, but, judging by this thread, I am far from\nthe only one who thinks much more needs done.",
"sig": "b15e1c657eda9682b975a15555ed7d9abff245fa1480a5ce2c8aeba953c6d29292d45cc43f852cb50e45d28ad976c5ccc1a1f846a8fb641aa90cedd94c8fa03a"
}