📅 Original date posted:2015-05-07
📝 Original message:That strikes me as a dangerous path forward.
I don't actually think there is anything wrong with this: "everybody
eventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and
we're left with the status quo"
What gives Bitcoin value aren't its technical merits but the fact that
people believe in it. The biggest risk here isn't that 20MB blocks will
be bad or that 1MB blocks will be bad, but that by forcing a hard fork that
isn't nearly universally agreed upon, we will be damaging that belief. If
I strongly believed some hard fork would be better for Bitcoin, say
permanent inflation of 1% a year to fund mining, and I managed to convince
80% of users, miners, businesses and developers to go along with me, I
would still vote against doing it. Because that's not nearly universal
agreement, and it changes what people chose to believe in without their
consent. Forks should be hard, very hard. And both sides should recognize
that belief in the value of Bitcoin might be a fragile thing. I'd argue
that if we didn't force through a 20MB fork now, and we ran into major
network difficulties a year from now and had no other technical solutions,
that maybe we would get nearly universal agreement, and the businesses and
users that were driven away by the unusable system would be a short term
loss in value considerably smaller than the impairment we risk by forcing a
change.
On Thu, May 7, 2015 at 10:52 AM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> For reference: the blog post that (re)-started this debate, and which
> links to individual issues, is here:
> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
>
> In it, I asked people to email me objections I might have missed. I would
> still appreciate it if people do that; it is impossible to keep up with
> this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and
> also have time to respond thoughtfully to the objections raised.
>
> I would very much like to find some concrete course of action that we can
> come to consensus on. Some compromise so we can tell entrepreneurs "THIS is
> how much transaction volume the main Bitcoin blockchain will be able to
> support over the next eleven years."
>
> I've been pretty clear on what I think is a reasonable compromise (a
> one-time increase scheduled for early next year), and I have tried to
> explain why I think it it is the right set of tradeoffs.
>
> There ARE tradeoffs here, and the hard question is what process do we use
> to decide those tradeoffs? How do we come to consensus? Is it worth my
> time to spend hours responding thoughtfully to every new objection raised
> here, or will the same thing happen that happened last year and the year
> before-- everybody eventually gets tired of arguing
> angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?
>
> I AM considering contributing some version of the bigger blocksize-limit
> hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist with a
> fast Internet connection, and assume Nelson's law to increase over time),
> and then encouraging merchants and exchanges and web wallets and
> individuals who think it strikes a reasonable balance to run it.
>
> And then, assuming it became a super-majority of nodes on the network,
> encourage miners to roll out a soft-fork to start producing bigger blocks
> and eventually trigger the hard fork.
>
> Because ultimately consensus comes down to what software people choose to
> run.
>
> --
> --
> Gavin Andresen
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/30afcdf6/attachment.html>;
Alex Morcos [ARCHIVE] /
npub10z…3xfzw
2023-06-07 15:33:10
in reply to nevent1q…sza9
Author Public Key
npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzwPublished at
2023-06-07 15:33:10Event JSON
{
"id": "044cfdd7186d5d5bf5da405a99b2f522d4eb78c544c6c9024e0f311ba8e0bd8b",
"pubkey": "78aa6925095b629d95a9e79aed6ed9da0973239bc6eedf11af42240f0e1d755c",
"created_at": 1686151990,
"kind": 1,
"tags": [
[
"e",
"0def597b074aa190bf159e12f9433ea74d157ee52321b38d195ba644ad5c177f",
"",
"root"
],
[
"e",
"a65ee1c9b0e121372fde12685531562787e2f588c847ddcbc4ccb2460724c8cd",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-05-07\n📝 Original message:That strikes me as a dangerous path forward.\n\nI don't actually think there is anything wrong with this: \"everybody\neventually gets tired of arguing angels-dancing-on-the-head-of-a-pin, and\nwe're left with the status quo\"\n\nWhat gives Bitcoin value aren't its technical merits but the fact that\npeople believe in it. The biggest risk here isn't that 20MB blocks will\nbe bad or that 1MB blocks will be bad, but that by forcing a hard fork that\nisn't nearly universally agreed upon, we will be damaging that belief. If\nI strongly believed some hard fork would be better for Bitcoin, say\npermanent inflation of 1% a year to fund mining, and I managed to convince\n80% of users, miners, businesses and developers to go along with me, I\nwould still vote against doing it. Because that's not nearly universal\nagreement, and it changes what people chose to believe in without their\nconsent. Forks should be hard, very hard. And both sides should recognize\nthat belief in the value of Bitcoin might be a fragile thing. I'd argue\nthat if we didn't force through a 20MB fork now, and we ran into major\nnetwork difficulties a year from now and had no other technical solutions,\nthat maybe we would get nearly universal agreement, and the businesses and\nusers that were driven away by the unusable system would be a short term\nloss in value considerably smaller than the impairment we risk by forcing a\nchange.\n\n\n\nOn Thu, May 7, 2015 at 10:52 AM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e\nwrote:\n\n\u003e For reference: the blog post that (re)-started this debate, and which\n\u003e links to individual issues, is here:\n\u003e http://gavinandresen.ninja/time-to-roll-out-bigger-blocks\n\u003e\n\u003e In it, I asked people to email me objections I might have missed. I would\n\u003e still appreciate it if people do that; it is impossible to keep up with\n\u003e this mailing list, /r/bitcoin posts and comments, and #bitcoin-wizards and\n\u003e also have time to respond thoughtfully to the objections raised.\n\u003e\n\u003e I would very much like to find some concrete course of action that we can\n\u003e come to consensus on. Some compromise so we can tell entrepreneurs \"THIS is\n\u003e how much transaction volume the main Bitcoin blockchain will be able to\n\u003e support over the next eleven years.\"\n\u003e\n\u003e I've been pretty clear on what I think is a reasonable compromise (a\n\u003e one-time increase scheduled for early next year), and I have tried to\n\u003e explain why I think it it is the right set of tradeoffs.\n\u003e\n\u003e There ARE tradeoffs here, and the hard question is what process do we use\n\u003e to decide those tradeoffs? How do we come to consensus? Is it worth my\n\u003e time to spend hours responding thoughtfully to every new objection raised\n\u003e here, or will the same thing happen that happened last year and the year\n\u003e before-- everybody eventually gets tired of arguing\n\u003e angels-dancing-on-the-head-of-a-pin, and we're left with the status quo?\n\u003e\n\u003e I AM considering contributing some version of the bigger blocksize-limit\n\u003e hard-fork patch to the Bitcoin-Xt fork (probably \"target a hobbyist with a\n\u003e fast Internet connection, and assume Nelson's law to increase over time),\n\u003e and then encouraging merchants and exchanges and web wallets and\n\u003e individuals who think it strikes a reasonable balance to run it.\n\u003e\n\u003e And then, assuming it became a super-majority of nodes on the network,\n\u003e encourage miners to roll out a soft-fork to start producing bigger blocks\n\u003e and eventually trigger the hard fork.\n\u003e\n\u003e Because ultimately consensus comes down to what software people choose to\n\u003e run.\n\u003e\n\u003e --\n\u003e --\n\u003e Gavin Andresen\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/30afcdf6/attachment.html\u003e",
"sig": "91d44d5a7808f82746601a14682c3e2d758b064cab18f71e86de0ed0854267a600f898b1c8c2fe873e539aa579a8f910fe143cd7da1cc0bf7bc5d58b515bf6ad"
}