š
Original date posted:2011-08-24
šļø Summary of this message: A discussion about the possibility of replacing hard limits on block size with something that can adapt dynamically, but it is deemed too early to make such a change.
š Original message:On Wed, Aug 24, 2011 at 10:19 AM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
> On Wed, Aug 24, 2011 at 1:07 PM, Rick Wesson
> <rick at support-intelligence.com> wrote:
> > On Wed, Aug 24, 2011 at 9:46 AM, Gregory Maxwell <gmaxwell at gmail.com>
> wrote:
> >> On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr <luke at dashjr.org> wrote:
> >>
> >> > - Replace hard limits (like 1 MB maximum block size) with something
> that
> >> > can
> >> > dynamically adapt with the times. Maybe based on difficulty so it
> can't
> >> > be
> >> > gamed?
> >> Too early for that.
> > Could you provide a reference to why in your estimation it is "to early."
> > Simpy stating this as fact isn't enough to sway demand.
>
> Can you provide a reference to this 'demand' a post by Luke isn't
> enough to support the claim of demand.
>
> how about trend, its a hard limit and as you acknowledged below we are not
there yet; however the trend is for more transactions and we will bump into
the limit. Being good architects we should consider how to scale or
explicitly state why its a good idea not to.
-rick
> We're not at maximum size right now (thankfully).
>
> We don't know what the network dynamics would look like at that
> traffic level. So how could we competently say what the right metrics
> would be to get the right behavior there? Thats what I meant by too
> early.
>
no one ever "knows" what the network dynamics are going to be in developing
infrastructure -- so lets not kid our selves, in being able to estimate this
before the code is even written.
-rick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110824/7ffd3502/attachment.html>;
Rick Wesson [ARCHIVE] /
npub1xzā¦2925u
2023-06-07 02:18:10
in reply to nevent1qā¦p63z
Author Public Key
npub1xz8q68hmzur6c6uje593nscy3q4njx05h4vnxmz2wxxptx7u7casl2925uPublished at
2023-06-07 02:18:10Event JSON
{
"id": "85de3686e0c973192f921b754425101c6a6adf01d1983ac4c6cf819a0ae72d90",
"pubkey": "308e0d1efb1707ac6b92cd0b19c304882b3919f4bd59336c4a718c159bdcf63b",
"created_at": 1686104290,
"kind": 1,
"tags": [
[
"e",
"391ebcb8eb3f9b5884cfbf66f4a99b12c015cc93baa9452c114d68f52d1168ec",
"",
"root"
],
[
"e",
"edf3988d2cfdbe28b8d5463f0f47df91357211430b722d67a8c12dbe1e35bc91",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "š
Original date posted:2011-08-24\nšļø Summary of this message: A discussion about the possibility of replacing hard limits on block size with something that can adapt dynamically, but it is deemed too early to make such a change.\nš Original message:On Wed, Aug 24, 2011 at 10:19 AM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003ewrote:\n\n\u003e On Wed, Aug 24, 2011 at 1:07 PM, Rick Wesson\n\u003e \u003crick at support-intelligence.com\u003e wrote:\n\u003e \u003e On Wed, Aug 24, 2011 at 9:46 AM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e\n\u003e wrote:\n\u003e \u003e\u003e On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e \u003e - Replace hard limits (like 1 MB maximum block size) with something\n\u003e that\n\u003e \u003e\u003e \u003e can\n\u003e \u003e\u003e \u003e dynamically adapt with the times. Maybe based on difficulty so it\n\u003e can't\n\u003e \u003e\u003e \u003e be\n\u003e \u003e\u003e \u003e gamed?\n\u003e \u003e\u003e Too early for that.\n\u003e \u003e Could you provide a reference to why in your estimation it is \"to early.\"\n\u003e \u003e Simpy stating this as fact isn't enough to sway demand.\n\u003e\n\u003e Can you provide a reference to this 'demand' a post by Luke isn't\n\u003e enough to support the claim of demand.\n\u003e\n\u003e how about trend, its a hard limit and as you acknowledged below we are not\nthere yet; however the trend is for more transactions and we will bump into\nthe limit. Being good architects we should consider how to scale or\nexplicitly state why its a good idea not to.\n\n-rick\n\n\n\n\u003e We're not at maximum size right now (thankfully).\n\u003e\n\u003e We don't know what the network dynamics would look like at that\n\u003e traffic level. So how could we competently say what the right metrics\n\u003e would be to get the right behavior there? Thats what I meant by too\n\u003e early.\n\u003e\n\nno one ever \"knows\" what the network dynamics are going to be in developing\ninfrastructure -- so lets not kid our selves, in being able to estimate this\nbefore the code is even written.\n\n-rick\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110824/7ffd3502/attachment.html\u003e",
"sig": "6660cc9a8abc92bc8cb41eefa0eb73659a206ce2f75e460b8022f456f9ce307ac58fca19ee5f48ab45a040ab812b9a553f892e4792735fb209a6c899b7c097ff"
}