📅 Original date posted:2015-05-07
📝 Original message:Hey Matt,
OK, let's get started ....
However, there hasnt been any discussion on this
> mailing list in several years as far as I can tell.
>
Probably because this list is not a good place for making progress or
reaching decisions. Those are triggered by pull requests (sometimes).
If you're wondering "why now", that's probably my fault. A few days ago
Wladimir posted a release timeline. I observed to Wladimir and Gavin in
private that this timeline meant a change to the block size was unlikely to
get into 0.11, leaving only 0.12, which would give everyone only a few
months to upgrade in order to fork the chain by the end of the winter
growth season. That seemed tight.
Wladimir did not reply to this email, unfortunately. Perhaps he would like
the issue to go away. It won't - if Bitcoin continues on its current growth
trends it *will* run out of capacity, almost certainly by some time next
year.
What we need to see right now is leadership and a plan, that fits in the
available time window.
> Certainly a consensus in this kind of technical community should be a
> basic requirement for any serious commitment to blocksize increase.
>
I'm afraid I have come to disagree. I no longer believe this community can
reach consensus on anything protocol related. Some of these arguments have
dragged on for years. Consensus isn't even well defined - consensus of who?
Anyone who shows up? And what happens when, inevitably, no consensus is
reached? Stasis forever?
> Long-term incentive compatibility requires that there be some fee
> pressure, and that blocks be relatively consistently full or very nearly
> full.
I disagree. When the money supply eventually dwindles I doubt it will be
fee pressure that funds mining, but as that's a long time in the future,
it's very hard to predict what might happen.
> What we see today are
> transactions enjoying next-block confirmations with nearly zero pressure
> to include any fee at all (though many do because it makes wallet code
> simpler).
>
Many do because free transactions are broken - the relay limiter means
whether a free transaction actually makes it across the network or not is
basically pot luck and there's no way for a wallet to know, short of either
trying it or actually receiving every single transaction and repeating the
calculations. If free transactions weren't broken for all non-full nodes
they'd probably be used a lot more.
> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale.
I have two huge problems with this line of thinking.
Firstly, no, the "Bitcoin ecosystem" is not well funded. Blockstream might
be, but significant numbers of users are running programs developed by tiny
startups, or volunteers who don't have millions in venture capital to play
with.
Arm-twisting "the ecosystem" into developing complicated Rube Goldberg
machines in double quick time, just to keep the Bitcoin show on the road,
is in fact the opposite of decentralisation - it will effectively exclude
anyone who isn't able to raise large amounts of corporate funding from
writing code that uses the Bitcoin network. Decentralisation benefits from
simplicity, and bigger blocks are (in Gavin's words) "the simplest thing
that will work".
My second problem is the claim that everyone is playing pretend about
Bitcoin, except you guys. I would put it another way - I would say those
people are building products and getting users, by making reasonable
engineering tradeoffs and using systems that work. Yes, one day those
systems might have to change. That's the nature of scaling. It's the nature
of progress. But not today. Probably not tomorrow either.
What I would like to see from Blockstream is a counter-proposal. So far you
have made lots of vague comments that we all agree with - yes,
decentralisation is good, yes some block size limit must exist, if only
because computers are finite machines.
What I don't see from you yet is a *specific and credible plan* that fits
within the next 12 months and which allows Bitcoin to keep growing. Not
some vague handwave like "let's all use the Lightning network" (which does
not exist), or "let's do more research" (Gavin has done plenty of
research), or "but what about the risks" (Bitcoin is full of risks). A
plan, with dates attached, and a strong chance of actually being deployed
in time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/81942b17/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:33:05
in reply to nevent1q…tqtz
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:33:05Event JSON
{
"id": "eb0f24c5dc517d2fd8674dff02497f0d093ad878d1303e9b0014070c50335274",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686151985,
"kind": 1,
"tags": [
[
"e",
"0def597b074aa190bf159e12f9433ea74d157ee52321b38d195ba644ad5c177f",
"",
"root"
],
[
"e",
"a99540d62bb46706ca0cb07f35850bc639f9e2ccb058f0242aa3723c2ab1b77c",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2015-05-07\n📝 Original message:Hey Matt,\n\nOK, let's get started ....\n\nHowever, there hasnt been any discussion on this\n\u003e mailing list in several years as far as I can tell.\n\u003e\n\nProbably because this list is not a good place for making progress or\nreaching decisions. Those are triggered by pull requests (sometimes).\n\nIf you're wondering \"why now\", that's probably my fault. A few days ago\nWladimir posted a release timeline. I observed to Wladimir and Gavin in\nprivate that this timeline meant a change to the block size was unlikely to\nget into 0.11, leaving only 0.12, which would give everyone only a few\nmonths to upgrade in order to fork the chain by the end of the winter\ngrowth season. That seemed tight.\n\nWladimir did not reply to this email, unfortunately. Perhaps he would like\nthe issue to go away. It won't - if Bitcoin continues on its current growth\ntrends it *will* run out of capacity, almost certainly by some time next\nyear.\n\nWhat we need to see right now is leadership and a plan, that fits in the\navailable time window.\n\n\n\u003e Certainly a consensus in this kind of technical community should be a\n\u003e basic requirement for any serious commitment to blocksize increase.\n\u003e\n\nI'm afraid I have come to disagree. I no longer believe this community can\nreach consensus on anything protocol related. Some of these arguments have\ndragged on for years. Consensus isn't even well defined - consensus of who?\nAnyone who shows up? And what happens when, inevitably, no consensus is\nreached? Stasis forever?\n\n\n\u003e Long-term incentive compatibility requires that there be some fee\n\u003e pressure, and that blocks be relatively consistently full or very nearly\n\u003e full.\n\n\nI disagree. When the money supply eventually dwindles I doubt it will be\nfee pressure that funds mining, but as that's a long time in the future,\nit's very hard to predict what might happen.\n\n\n\u003e What we see today are\n\u003e transactions enjoying next-block confirmations with nearly zero pressure\n\u003e to include any fee at all (though many do because it makes wallet code\n\u003e simpler).\n\u003e\n\nMany do because free transactions are broken - the relay limiter means\nwhether a free transaction actually makes it across the network or not is\nbasically pot luck and there's no way for a wallet to know, short of either\ntrying it or actually receiving every single transaction and repeating the\ncalculations. If free transactions weren't broken for all non-full nodes\nthey'd probably be used a lot more.\n\n\n\u003e This allows the well-funded Bitcoin ecosystem to continue building\n\u003e systems which rely on transactions moving quickly into blocks while\n\u003e pretending these systems scale.\n\n\nI have two huge problems with this line of thinking.\n\nFirstly, no, the \"Bitcoin ecosystem\" is not well funded. Blockstream might\nbe, but significant numbers of users are running programs developed by tiny\nstartups, or volunteers who don't have millions in venture capital to play\nwith.\n\nArm-twisting \"the ecosystem\" into developing complicated Rube Goldberg\nmachines in double quick time, just to keep the Bitcoin show on the road,\nis in fact the opposite of decentralisation - it will effectively exclude\nanyone who isn't able to raise large amounts of corporate funding from\nwriting code that uses the Bitcoin network. Decentralisation benefits from\nsimplicity, and bigger blocks are (in Gavin's words) \"the simplest thing\nthat will work\".\n\nMy second problem is the claim that everyone is playing pretend about\nBitcoin, except you guys. I would put it another way - I would say those\npeople are building products and getting users, by making reasonable\nengineering tradeoffs and using systems that work. Yes, one day those\nsystems might have to change. That's the nature of scaling. It's the nature\nof progress. But not today. Probably not tomorrow either.\n\nWhat I would like to see from Blockstream is a counter-proposal. So far you\nhave made lots of vague comments that we all agree with - yes,\ndecentralisation is good, yes some block size limit must exist, if only\nbecause computers are finite machines.\n\nWhat I don't see from you yet is a *specific and credible plan* that fits\nwithin the next 12 months and which allows Bitcoin to keep growing. Not\nsome vague handwave like \"let's all use the Lightning network\" (which does\nnot exist), or \"let's do more research\" (Gavin has done plenty of\nresearch), or \"but what about the risks\" (Bitcoin is full of risks). A\nplan, with dates attached, and a strong chance of actually being deployed\nin time.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/81942b17/attachment.html\u003e",
"sig": "682ed69753bbaa2f21c5b900c53947ae33a070c556b1a17d371353526d4d99f3caaae375079b1e7c4c3d84e50e3fbfa461e5b25aed9bac9b09f353d33f0b95d4"
}