š
Original date posted:2015-06-01
š Original message:> Let the block size limit be a function of the number of current transactions
in the mempool.
There is no single mempool which transactions could be counted and there is
no consensus about the average number of unconfirmed transactions.
2015-06-01 13:30 GMT+02:00 Ricardo Filipe <ricardojdfilipe at gmail.com>:
> I've been following the discussion of the block size limit and IMO it
> is clear that any constant block size limit is, as many have said
> before, just kicking the can down the road.
> My problem with the dynamic lower limit solution based on past blocks
> is that it doesn't account for usage spikes. I would like to propose
> another dynamic lower limit scheme:
> Let the block size limit be a function of the number of current
> transactions in the mempool. This way, bitcoin usage regulates the
> block size limit.
>
> I'm sorry i don't have the knowledge of the code base or time to make
> simulations on this kind of approach, but nevertheless I would like to
> leave it here for discussion or foster other ideas.
>
> cheers
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/7027163a/attachment.html>;
Marcel Jamin [ARCHIVE] /
npub14jā¦vk3rk
2023-06-07 15:36:11
in reply to nevent1qā¦n9wu
Author Public Key
npub14jegtpz2t9nfnefqqr0q4te9353e4k4x5y2528qf235ruluzsaes8vk3rkPublished at
2023-06-07 15:36:11Event JSON
{
"id": "951028d6c3fb107bedc2f50a70f2c5ef115726da649d5c91d5d5a5b11918676e",
"pubkey": "acb285844a596699e52000de0aaf258d239adaa6a115451c0954683e7f828773",
"created_at": 1686152171,
"kind": 1,
"tags": [
[
"e",
"1e38abcc0ac9866c0c230791aba9503f9a56458bc3bf3e186c85f950f01de96d",
"",
"root"
],
[
"e",
"047ef63fd11b35238bf464ce8bbf801c381bc40edda88f987be13286ee43b40c",
"",
"reply"
],
[
"p",
"aa5cd512f153f77aa335d71793f2cd219569188aedabd7d0239386b17f7728d8"
]
],
"content": "š
Original date posted:2015-06-01\nš Original message:\u003e Let the block size limit be a function of the number of current transactions\nin the mempool.\n\nThere is no single mempool which transactions could be counted and there is\nno consensus about the average number of unconfirmed transactions.\n\n2015-06-01 13:30 GMT+02:00 Ricardo Filipe \u003cricardojdfilipe at gmail.com\u003e:\n\n\u003e I've been following the discussion of the block size limit and IMO it\n\u003e is clear that any constant block size limit is, as many have said\n\u003e before, just kicking the can down the road.\n\u003e My problem with the dynamic lower limit solution based on past blocks\n\u003e is that it doesn't account for usage spikes. I would like to propose\n\u003e another dynamic lower limit scheme:\n\u003e Let the block size limit be a function of the number of current\n\u003e transactions in the mempool. This way, bitcoin usage regulates the\n\u003e block size limit.\n\u003e\n\u003e I'm sorry i don't have the knowledge of the code base or time to make\n\u003e simulations on this kind of approach, but nevertheless I would like to\n\u003e leave it here for discussion or foster other ideas.\n\u003e\n\u003e cheers\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150601/7027163a/attachment.html\u003e",
"sig": "dd4523fc2040511de4d73fb33655cacaa79bcdc6b62d80a53d68ec84cd6a3dbb46cae7eda1caa9c08696fae84cee50cc133aa4bd6f8be7e4e41b1f0bc10f46ed"
}