📅 Original date posted:2015-09-08
📝 Original message:> but allow meaningful relief to transaction volume pressure in response to true market demand
If blocksize can only increase then it's like a market that only goes
up which is unrealistic. Transaction will volume ebb and flow
significantly. Some people have been looking at transaction volume
charts over time and all they can see is an exponential curve which
they think will go on forever, yet nothing goes up forever and it will
go through significant trend cycles (like everything does). If you
dont want to hurt the fee market, the blocksize has to be elastic and
allow contraction as well as expansion.
On Tue, Sep 8, 2015 at 8:45 AM, Washington Sanchez via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi everyone,
>
> I know many of us feel that the last thing the Bitcoin community needs is
> another BIP related to the block size, but after a lot of reading and
> commenting, I'd like to throw this idea out there.
>
> I've already written it up as a BIP and would like some constructive
> feedback/suggestions/alternatives related to some of the variables in my
> specification:
>
>
> Dynamic limit to the block size
> =======================
>
> The goal is to dynamically increase the maximum block size conservatively,
> but allow meaningful relief to transaction volume pressure in response to
> true market demand. The specification follows:
>
> - Every 4032 blocks (~4 weeks), the maximum block size will be increased by
> 10% *IF* a minimum of 2000 blocks has a size >= 60% of the maximum block
> size at that time
> + This calculates to theoretically 13 increases per year
> - The maximum block size can only ever be increased, not decreased
>
> For example, if this rule were to be instituted January 1st 2016, with a
> present maximum block size 1 MB, the limit would be increased to 1.1 MB on
> January 29th 2016. The theoretical maximum block size at the end of 2016
> would be ~3.45 MB, assuming all 13 increases are triggered.
>
> As the maximum block size rises, so the cost of artificially triggering an
> increase in the maximum block size.
>
>
> Regards,
> Wash
>
>
> -------------------------------------------
> Dr Washington Y. Sanchez
> Co-founder, OB1
> Core developer of OpenBazaar
> @drwasho
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Btc Drak [ARCHIVE] /
npub1lh…zg7ed
2023-06-07 17:39:48
in reply to nevent1q…xf52
Author Public Key
npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7edSeen on
wss://relay.noswhere.comPublished at
2023-06-07 17:39:48Event JSON
{
"id": "cd1a84555c103fdd1799a9f84b46621320a50ceab54895990a95a97d607c09cb",
"pubkey": "fdf31024ca0537ed828d895ddc8525f8af023f0dc935a8327a8a496d0d7a9f83",
"created_at": 1686159588,
"kind": 1,
"tags": [
[
"e",
"5db98b1bb8a695c5ded066d359dd1edd37b2315bd6a400566e7871f0b2f043bb",
"",
"root"
],
[
"e",
"4cf640cd5c565068d5e49916a8b1008e09306f8b94ad142fd873fed3a9076e16",
"",
"reply"
],
[
"p",
"44f6b1bc34db0cd6a353de4e8d2dcdd62b94272c5645619539442dd563a160d3"
]
],
"content": "📅 Original date posted:2015-09-08\n📝 Original message:\u003e but allow meaningful relief to transaction volume pressure in response to true market demand\n\nIf blocksize can only increase then it's like a market that only goes\nup which is unrealistic. Transaction will volume ebb and flow\nsignificantly. Some people have been looking at transaction volume\ncharts over time and all they can see is an exponential curve which\nthey think will go on forever, yet nothing goes up forever and it will\ngo through significant trend cycles (like everything does). If you\ndont want to hurt the fee market, the blocksize has to be elastic and\nallow contraction as well as expansion.\n\nOn Tue, Sep 8, 2015 at 8:45 AM, Washington Sanchez via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e Hi everyone,\n\u003e\n\u003e I know many of us feel that the last thing the Bitcoin community needs is\n\u003e another BIP related to the block size, but after a lot of reading and\n\u003e commenting, I'd like to throw this idea out there.\n\u003e\n\u003e I've already written it up as a BIP and would like some constructive\n\u003e feedback/suggestions/alternatives related to some of the variables in my\n\u003e specification:\n\u003e\n\u003e\n\u003e Dynamic limit to the block size\n\u003e =======================\n\u003e\n\u003e The goal is to dynamically increase the maximum block size conservatively,\n\u003e but allow meaningful relief to transaction volume pressure in response to\n\u003e true market demand. The specification follows:\n\u003e\n\u003e - Every 4032 blocks (~4 weeks), the maximum block size will be increased by\n\u003e 10% *IF* a minimum of 2000 blocks has a size \u003e= 60% of the maximum block\n\u003e size at that time\n\u003e + This calculates to theoretically 13 increases per year\n\u003e - The maximum block size can only ever be increased, not decreased\n\u003e\n\u003e For example, if this rule were to be instituted January 1st 2016, with a\n\u003e present maximum block size 1 MB, the limit would be increased to 1.1 MB on\n\u003e January 29th 2016. The theoretical maximum block size at the end of 2016\n\u003e would be ~3.45 MB, assuming all 13 increases are triggered.\n\u003e\n\u003e As the maximum block size rises, so the cost of artificially triggering an\n\u003e increase in the maximum block size.\n\u003e\n\u003e\n\u003e Regards,\n\u003e Wash\n\u003e\n\u003e\n\u003e -------------------------------------------\n\u003e Dr Washington Y. Sanchez\n\u003e Co-founder, OB1\n\u003e Core developer of OpenBazaar\n\u003e @drwasho\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",
"sig": "41a2bed6d2b9d99dfa20a6441bdaad4e10056348f0dd4975ddc0f67a3953b113709b44ac2b12d48e14bc4992b8155c1cccc3ae97af2e0a76aa2328112e446c9b"
}