📅 Original date posted:2015-11-13
📝 Original message:I believe in the end it's the usability of bitcoin that matters.
For instance, a goal could be that no user on the network should wait more
than an hour to get 3 confirmations on the blockchain so that they can
actually have useful Bitcoins.
We can debate all we want about lots of technical aspects, but if you can't
send money what's the point?
My humble proposal tried to take that into consideration, but I like way
way more what you propose with NG.
http://twitter.com/gubatron
On Fri, Nov 13, 2015 at 11:37 AM, Emin Gün Sirer <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> By now, we have seen quite a few proposals for the block size increase.
> It's hard not to notice that there are potentially infinitely many
> functions for future block size increases. One could, for instance, double
> every N years for any rational number N, one could increase linearly, one
> could double initially then increase linearly, one could ask the miners to
> vote on the size, one could couple the block size increase to halvings,
> etc. Without judging any of these proposals on the table, one can see that
> there are countless alternative functions one could imagine creating.
>
> I'd like to ask a question that is one notch higher: Can we enunciate what
> grand goals a truly perfect function would achieve? That is, if we could
> look into the future and know all the improvements to come in network
> access technologies, see the expansion of the Bitcoin network across the
> globe, and precisely know the placement and provisioning of all future
> nodes, what metrics would we care about as we craft a function to fit what
> is to come?
>
> To be clear, I'd like to avoid discussing any specific block size increase
> function. That's very much the tangible (non-meta) block size debate, and
> everyone has their opinion and best good-faith attempt at what that
> function should look like. I've purposefully stayed out of that issue,
> because there are too many options and no metrics for evaluating proposals.
>
> Instead, I'm asking to see if there is some agreement on how to evaluate a
> good proposal. So, the meta-question: if we were looking at the best
> possible function, how would we know? If we have N BIPs to choose from,
> what criteria do we look for?
>
> To illustrate, a possible meta goal might be: "increase the block size,
> while ensuring that large miners never have an advantage over small miners
> that [they did not have in the preceding 6 months, in 2012, pick your time
> frame, or else specify the advantage in an absolute fashion]." Or "increase
> block size as much as possible, subject to the constraint that 90% of the
> nodes on the network are no more than 1 minute behind one of the tails of
> the blockchain 99% of the time." Or "do not increase the blocksize until at
> least date X." Or "the increase function should be monotonic." And it's
> quite OK (and probably likely) to have a combination of these kinds of
> metrics and constraints.
>
> For disclosure, I personally do not have a horse in the block size debate,
> besides wanting to see Bitcoin evolve and get more widely adopted. I ask
> because as an academic, I'd like to understand if we can use various
> simulation and analytic techniques to examine the proposals. A second
> reason is that it is very easy to have a proliferation of block size
> increase proposals, and good engineering would ask that we define the
> meta-criteria first and then pick. To do that, we need some criteria for
> judging proposals other than gut feeling.
>
> Of course, even with meta-criteria in hand, there will be room for lots of
> disagreement because we do not actually know the future and reasonable
> people can disagree on how things will evolve. I think this is good because
> it makes it easier to agree on meta-criteria than on an actual, specific
> function for increasing the block size.
>
> It looks like some specific meta-level criteria would help more at this
> point than new proposals all exploring a different variants of block size
> increase schedules.
>
> Best,
>
> - egs
>
>
> P.S. This message is an off-shoot of this blog post:
>
>
> http://hackingdistributed.com/2015/11/13/suggestion-for-the-blocksize-debate/
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151113/4b303813/attachment-0001.html>;
Angel Leon [ARCHIVE] /
npub1c8…zgzt8
2023-06-07 17:44:47
in reply to nevent1q…632z
Author Public Key
npub1c8flqlwmkh5vehm7rfcacurk9x5ggv36vtra2p97thynzfq0vxus5zgzt8Published at
2023-06-07 17:44:47Event JSON
{
"id": "e494483078b63d034611afa7f2d74a5673bb1471d2e5b05723185ba464618f3c",
"pubkey": "c1d3f07ddbb5e8ccdf7e1a71dc707629a884323a62c7d504be5dc931240f61b9",
"created_at": 1686159887,
"kind": 1,
"tags": [
[
"e",
"3a0a71e06daf4df40d34d7d4df38f6afd927082ae4667eeee9d89bbe73cc655b",
"",
"root"
],
[
"e",
"d44f12dfaf08331bfc089c30fb440ec495ef1bcd2388b970d893a79cc730aa78",
"",
"reply"
],
[
"p",
"b68afd106d166cdb4d51d8e16c275c09e0a49020fb6f311509c56b6743b37a84"
]
],
"content": "📅 Original date posted:2015-11-13\n📝 Original message:I believe in the end it's the usability of bitcoin that matters.\n\nFor instance, a goal could be that no user on the network should wait more\nthan an hour to get 3 confirmations on the blockchain so that they can\nactually have useful Bitcoins.\n\nWe can debate all we want about lots of technical aspects, but if you can't\nsend money what's the point?\n\nMy humble proposal tried to take that into consideration, but I like way\nway more what you propose with NG.\n\nhttp://twitter.com/gubatron\n\nOn Fri, Nov 13, 2015 at 11:37 AM, Emin Gün Sirer \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e By now, we have seen quite a few proposals for the block size increase.\n\u003e It's hard not to notice that there are potentially infinitely many\n\u003e functions for future block size increases. One could, for instance, double\n\u003e every N years for any rational number N, one could increase linearly, one\n\u003e could double initially then increase linearly, one could ask the miners to\n\u003e vote on the size, one could couple the block size increase to halvings,\n\u003e etc. Without judging any of these proposals on the table, one can see that\n\u003e there are countless alternative functions one could imagine creating.\n\u003e\n\u003e I'd like to ask a question that is one notch higher: Can we enunciate what\n\u003e grand goals a truly perfect function would achieve? That is, if we could\n\u003e look into the future and know all the improvements to come in network\n\u003e access technologies, see the expansion of the Bitcoin network across the\n\u003e globe, and precisely know the placement and provisioning of all future\n\u003e nodes, what metrics would we care about as we craft a function to fit what\n\u003e is to come?\n\u003e\n\u003e To be clear, I'd like to avoid discussing any specific block size increase\n\u003e function. That's very much the tangible (non-meta) block size debate, and\n\u003e everyone has their opinion and best good-faith attempt at what that\n\u003e function should look like. I've purposefully stayed out of that issue,\n\u003e because there are too many options and no metrics for evaluating proposals.\n\u003e\n\u003e Instead, I'm asking to see if there is some agreement on how to evaluate a\n\u003e good proposal. So, the meta-question: if we were looking at the best\n\u003e possible function, how would we know? If we have N BIPs to choose from,\n\u003e what criteria do we look for?\n\u003e\n\u003e To illustrate, a possible meta goal might be: \"increase the block size,\n\u003e while ensuring that large miners never have an advantage over small miners\n\u003e that [they did not have in the preceding 6 months, in 2012, pick your time\n\u003e frame, or else specify the advantage in an absolute fashion].\" Or \"increase\n\u003e block size as much as possible, subject to the constraint that 90% of the\n\u003e nodes on the network are no more than 1 minute behind one of the tails of\n\u003e the blockchain 99% of the time.\" Or \"do not increase the blocksize until at\n\u003e least date X.\" Or \"the increase function should be monotonic.\" And it's\n\u003e quite OK (and probably likely) to have a combination of these kinds of\n\u003e metrics and constraints.\n\u003e\n\u003e For disclosure, I personally do not have a horse in the block size debate,\n\u003e besides wanting to see Bitcoin evolve and get more widely adopted. I ask\n\u003e because as an academic, I'd like to understand if we can use various\n\u003e simulation and analytic techniques to examine the proposals. A second\n\u003e reason is that it is very easy to have a proliferation of block size\n\u003e increase proposals, and good engineering would ask that we define the\n\u003e meta-criteria first and then pick. To do that, we need some criteria for\n\u003e judging proposals other than gut feeling.\n\u003e\n\u003e Of course, even with meta-criteria in hand, there will be room for lots of\n\u003e disagreement because we do not actually know the future and reasonable\n\u003e people can disagree on how things will evolve. I think this is good because\n\u003e it makes it easier to agree on meta-criteria than on an actual, specific\n\u003e function for increasing the block size.\n\u003e\n\u003e It looks like some specific meta-level criteria would help more at this\n\u003e point than new proposals all exploring a different variants of block size\n\u003e increase schedules.\n\u003e\n\u003e Best,\n\u003e\n\u003e - egs\n\u003e\n\u003e\n\u003e P.S. This message is an off-shoot of this blog post:\n\u003e\n\u003e\n\u003e http://hackingdistributed.com/2015/11/13/suggestion-for-the-blocksize-debate/\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151113/4b303813/attachment-0001.html\u003e",
"sig": "122db12b18d0f8b32a3e65b4e36f2cc3c4cae2dca7c1d1230d1dbee26ebce5d850d7abe275398fa3bc4759704354fd57b2bfc201b1a3cf305a1b63028a2b49aa"
}