đź“… Original date posted:2015-06-14
đź“ť Original message:Exactly -- both block size proponents and block size change conservatives
seem to be glossing over this aspect - much to my dismay.
Choosing the size limit is choosing the size of a scarce resource. By fiat.
It is wrong to think that a "technical consensus" can choose what is best
here.
The block size limit defines the scope of a resource for which all fee
market actors bid. That, in turn, defines who is in the fee market and how
they behave, what market choices are made.
It doesn't matter how or why the limit was originally enacted, what Satoshi
meant to do. What matters, economically, is what is. What the software
and our $3B economy & market knows and sees today. (I think some block
size change proponents miss this!)
The solution lies in transitioning this size limit to the free market. In
the end, the users must choose their desired level of growth,
decentralization, etc. We cannot rely on some dev's idea of the proper
level of fee, proper level of growth, proper level of decentralization.
And IMO, a "floating limit with training wheels" is better and stronger for
bitcoin's health from a governance, user choice and free market perspective
than simply "hard fork to 2MB, come back again in 6 months."
On Sun, Jun 14, 2015 at 6:34 AM, Benjamin <benjamin.l.cordes at gmail.com>
wrote:
> "The size limit is an economic policy lever that needs to be
> transitioned -away- from software and software developers, to the free
> market."
>
> Exactly right. Bitcoin does not have a free market for fee though, and
> literally all the discussion so far has neglected some fundamental
> aspect of this, as you described. It's not at all a "technical" or
> "engineering" decision. It's the question of how to potentially
> re-design a fundamental part of Bitcoin, and the proposals so far
> don't address this. What is the price of the scarce resource of the
> blockchain and the mechanism to decide on price, once the subsidy runs
> out?
>
> On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson <mats at henricson.se>
> wrote:
> > Jeff,
> >
> > with all due respect, but I've seen you saying this a few times
> > now, that this decision is oh so difficult and important.
> >
> > But this is not helpful. We all know that. Even I.
> >
> > Make a suggestion, or stay out of the debate!
> >
> > Mats
> >
> > On 06/14/2015 07:36 AM, Jeff Garzik wrote:
> >> The choice is very real and on-point. What should the block size limit
> >> be? Why?
> >>
> >> There is a large consensus that it needs increasing. To what? By what
> >> factor?
> >>
> >> The size limit literally defines the fee market, the whole damn thing.
> If
> >> software high priests choose a size limit of 300k, space is scarce, fees
> >> are bid high. If software high priests choose a size limit of 32mb,
> space
> >> is plentiful, fees are near zero. Market actors take their signals
> >> accordingly. Some business models boom, some business models fail, as a
> >> direct result of changing this unintentionally-added speedbump.
> Different
> >> users value adoption, decentralization etc. differently.
> >>
> >> The size limit is an economic policy lever that needs to be transitioned
> >> -away- from software and software developers, to the free market.
> >>
> >> A simple, e.g. hard fork to 2MB or 4MB does not fix higher level
> governance
> >> problems associated with actors lobbying developers, even if a
> cloistered
> >> and vetted Technical Advisory Board as has been proposed.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo <elombrozo at gmail.com>
> wrote:
> >>
> >>> I definitely think we need some voting system for metaconsensus…but if
> >>> we’re going to seriously consider this we should look at the problem
> much
> >>> more generally. Using false choices doesn’t really help, though ;)
> >>>
> >>> - Eric Lombrozo
> >>>
> >>>
> >>> On Jun 13, 2015, at 10:13 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
> >>>
> >>> On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo <elombrozo at gmail.com>
> >>> wrote:
> >>>
> >>>> 2) BIP100 has direct economic consequences…and particularly for
> miners.
> >>>> It lends itself to much greater corruptibility.
> >>>>
> >>>>
> >>> What is the alternative? Have a Chief Scientist or Technical Advisory
> >>> Board choose what is a proper fee, what is a proper level of
> >>> decentralization, a proper growth factor?
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >>
> >>
> >>
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150614/48bfb14a/attachment.html>;
Jeff Garzik [ARCHIVE] /
npub1kf…f3f58
2023-06-07 15:37:33
in reply to nevent1q…rtcx
Author Public Key
npub1kf0ppcjaguxekg24yx6smgxlu73qn0k8lm0t2wrqc0scpl7u3sgsmf3f58Published at
2023-06-07 15:37:33Event JSON
{
"id": "3c245c06978176de8a14f2569de4837586d3f00644eee06c543b33d06e04c1b6",
"pubkey": "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11",
"created_at": 1686152253,
"kind": 1,
"tags": [
[
"e",
"8a807127e1ae5b585bcc8f3578413a7d3eb1bd30e75c19cd4a3a0a256adcb61c",
"",
"root"
],
[
"e",
"8a43d1468411b052df4f4d47f7c747f71fc1488a8ef2d601fa4b561b02bf2813",
"",
"reply"
],
[
"p",
"f5854a07c480aa95b00a3106a17778f7b58221d8dd12d11e6d9465ba737bd50c"
]
],
"content": "📅 Original date posted:2015-06-14\n📝 Original message:Exactly -- both block size proponents and block size change conservatives\nseem to be glossing over this aspect - much to my dismay.\n\nChoosing the size limit is choosing the size of a scarce resource. By fiat.\n\nIt is wrong to think that a \"technical consensus\" can choose what is best\nhere.\n\nThe block size limit defines the scope of a resource for which all fee\nmarket actors bid. That, in turn, defines who is in the fee market and how\nthey behave, what market choices are made.\n\nIt doesn't matter how or why the limit was originally enacted, what Satoshi\nmeant to do. What matters, economically, is what is. What the software\nand our $3B economy \u0026 market knows and sees today. (I think some block\nsize change proponents miss this!)\n\nThe solution lies in transitioning this size limit to the free market. In\nthe end, the users must choose their desired level of growth,\ndecentralization, etc. We cannot rely on some dev's idea of the proper\nlevel of fee, proper level of growth, proper level of decentralization.\n\nAnd IMO, a \"floating limit with training wheels\" is better and stronger for\nbitcoin's health from a governance, user choice and free market perspective\nthan simply \"hard fork to 2MB, come back again in 6 months.\"\n\n\n\n\n\n\n\nOn Sun, Jun 14, 2015 at 6:34 AM, Benjamin \u003cbenjamin.l.cordes at gmail.com\u003e\nwrote:\n\n\u003e \"The size limit is an economic policy lever that needs to be\n\u003e transitioned -away- from software and software developers, to the free\n\u003e market.\"\n\u003e\n\u003e Exactly right. Bitcoin does not have a free market for fee though, and\n\u003e literally all the discussion so far has neglected some fundamental\n\u003e aspect of this, as you described. It's not at all a \"technical\" or\n\u003e \"engineering\" decision. It's the question of how to potentially\n\u003e re-design a fundamental part of Bitcoin, and the proposals so far\n\u003e don't address this. What is the price of the scarce resource of the\n\u003e blockchain and the mechanism to decide on price, once the subsidy runs\n\u003e out?\n\u003e\n\u003e On Sun, Jun 14, 2015 at 12:06 PM, Mats Henricson \u003cmats at henricson.se\u003e\n\u003e wrote:\n\u003e \u003e Jeff,\n\u003e \u003e\n\u003e \u003e with all due respect, but I've seen you saying this a few times\n\u003e \u003e now, that this decision is oh so difficult and important.\n\u003e \u003e\n\u003e \u003e But this is not helpful. We all know that. Even I.\n\u003e \u003e\n\u003e \u003e Make a suggestion, or stay out of the debate!\n\u003e \u003e\n\u003e \u003e Mats\n\u003e \u003e\n\u003e \u003e On 06/14/2015 07:36 AM, Jeff Garzik wrote:\n\u003e \u003e\u003e The choice is very real and on-point. What should the block size limit\n\u003e \u003e\u003e be? Why?\n\u003e \u003e\u003e\n\u003e \u003e\u003e There is a large consensus that it needs increasing. To what? By what\n\u003e \u003e\u003e factor?\n\u003e \u003e\u003e\n\u003e \u003e\u003e The size limit literally defines the fee market, the whole damn thing.\n\u003e If\n\u003e \u003e\u003e software high priests choose a size limit of 300k, space is scarce, fees\n\u003e \u003e\u003e are bid high. If software high priests choose a size limit of 32mb,\n\u003e space\n\u003e \u003e\u003e is plentiful, fees are near zero. Market actors take their signals\n\u003e \u003e\u003e accordingly. Some business models boom, some business models fail, as a\n\u003e \u003e\u003e direct result of changing this unintentionally-added speedbump.\n\u003e Different\n\u003e \u003e\u003e users value adoption, decentralization etc. differently.\n\u003e \u003e\u003e\n\u003e \u003e\u003e The size limit is an economic policy lever that needs to be transitioned\n\u003e \u003e\u003e -away- from software and software developers, to the free market.\n\u003e \u003e\u003e\n\u003e \u003e\u003e A simple, e.g. hard fork to 2MB or 4MB does not fix higher level\n\u003e governance\n\u003e \u003e\u003e problems associated with actors lobbying developers, even if a\n\u003e cloistered\n\u003e \u003e\u003e and vetted Technical Advisory Board as has been proposed.\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo \u003celombrozo at gmail.com\u003e\n\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e\u003e I definitely think we need some voting system for metaconsensus…but if\n\u003e \u003e\u003e\u003e we’re going to seriously consider this we should look at the problem\n\u003e much\n\u003e \u003e\u003e\u003e more generally. Using false choices doesn’t really help, though ;)\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e - Eric Lombrozo\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e On Jun 13, 2015, at 10:13 PM, Jeff Garzik \u003cjgarzik at bitpay.com\u003e wrote:\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo \u003celombrozo at gmail.com\u003e\n\u003e \u003e\u003e\u003e wrote:\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\u003e 2) BIP100 has direct economic consequences…and particularly for\n\u003e miners.\n\u003e \u003e\u003e\u003e\u003e It lends itself to much greater corruptibility.\n\u003e \u003e\u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\u003e\n\u003e \u003e\u003e\u003e What is the alternative? Have a Chief Scientist or Technical Advisory\n\u003e \u003e\u003e\u003e Board choose what is a proper fee, what is a proper level of\n\u003e \u003e\u003e\u003e decentralization, a proper growth factor?\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e _______________________________________________\n\u003e \u003e\u003e Bitcoin-development mailing list\n\u003e \u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e _______________________________________________\n\u003e \u003e Bitcoin-development mailing list\n\u003e \u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\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\n\n\n-- \nJeff Garzik\nBitcoin core developer and open source evangelist\nBitPay, Inc. https://bitpay.com/\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150614/48bfb14a/attachment.html\u003e",
"sig": "63e370e57004afdebec35229236cf0a982e75ad1daa1c3d1fde5e4303088541b99b17c736330312565cf3f4a9bb671d83f4dbdd2ea33c2a78a207f3efde363bd"
}