📅 Original date posted:2015-05-08
📝 Original message:Matt,
It seems you missed my suggestion about basing the maximum block size on
the bitcoin days destroyed in transactions that are included in the block.
I think it has potential for both scaling as well as keeping up a constant
fee pressure. If tuned properly, it should both stop spamming and increase
block size maximum when there are a lot of real transactions waiting for
inclusion.
- Joel
On Fri, May 8, 2015 at 1:30 PM, Clément Elbaz <clem.ds at gmail.com> wrote:
> Matt : I think proposal #1 and #3 are a lot better than #2, and #1 is my
> favorite.
>
> I see two problems with proposal #2.
> The first problem with proposal #2 is that, as we see in democracies,
> there is often a mismatch between the people conscious vote and these same
> people behavior.
>
> Relying on an intentional vote made consciously by miners by choosing a
> configuration value can lead to twisted results if their actual behavior
> doesn't correlate with their vote (eg, they all vote for a small block size
> because it is the default configuration of their software, and then they
> fill it completely all the time and everything crashes).
>
> The second problem with proposal #2 is that if Gavin and Mike are right,
> there is simply no time to gather a meaningful amount of votes over the
> coinbases, after the fork but before the Bitcoin scalability crash.
>
> I like proposal #1 because the "vote" is made using already available
> data. Also there is no possible mismatch between behavior and vote. As a
> miner you vote by choosing to create a big (or small) block, and your
> actions reflect your vote. It is simple and straightforward.
>
> My feelings on proposal #3 is it is a little bit mixing apples and
> oranges, but I may not seeing all the implications.
>
>
> Le ven. 8 mai 2015 à 09:21, Matt Whitlock <bip at mattwhitlock.name> a
> écrit :
>
>> Between all the flames on this list, several ideas were raised that did
>> not get much attention. I hereby resubmit these ideas for consideration and
>> discussion.
>>
>> - Perhaps the hard block size limit should be a function of the actual
>> block sizes over some trailing sampling period. For example, take the
>> median block size among the most recent 2016 blocks and multiply it by 1.5.
>> This allows Bitcoin to scale up gradually and organically, rather than
>> having human beings guessing at what is an appropriate limit.
>>
>> - Perhaps the hard block size limit should be determined by a vote of the
>> miners. Each miner could embed a desired block size limit in the coinbase
>> transactions of the blocks it publishes. The effective hard block size
>> limit would be that size having the greatest number of votes within a
>> sliding window of most recent blocks.
>>
>> - Perhaps the hard block size limit should be a function of block-chain
>> length, so that it can scale up smoothly rather than jumping immediately to
>> 20 MB. This function could be linear (anticipating a breakdown of Moore's
>> Law) or quadratic.
>>
>> I would be in support of any of the above, but I do not support Mike
>> Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the
>> road without actually solving the problem, and it does so in a
>> controversial (step function) way.
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> 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/20150508/b6a95d5e/attachment.html>;
Joel Joonatan Kaartinen [ARCHIVE] /
npub165…48xrx
2023-06-07 15:33:55
in reply to nevent1q…edjl
Author Public Key
npub1654pkuj4rway0043gcu6rdh4umxescp7ew42d2czqvts3kwvg3esc48xrxPublished at
2023-06-07 15:33:55Event JSON
{
"id": "30b5cdf59a68c3961ae2736a893eda7362651c138b1fd345709310256bf61a20",
"pubkey": "d52a1b72551bba47beb14639a1b6f5e6cd98603ecbaaa6ab02031708d9cc4473",
"created_at": 1686152035,
"kind": 1,
"tags": [
[
"e",
"aec396df7693e37c124fbd2891fe6c4a3b28f46e7fbc3f304a7b1d78d2f5ffbe",
"",
"root"
],
[
"e",
"0f431247f0a6aa08fa05548acb6e73b32c5f69df093bf705ef809e6f779d3558",
"",
"reply"
],
[
"p",
"d5530ce76aaee2368403b00b2b1a93ab743ab90fc2eee3eb4547511340534247"
]
],
"content": "📅 Original date posted:2015-05-08\n📝 Original message:Matt,\n\nIt seems you missed my suggestion about basing the maximum block size on\nthe bitcoin days destroyed in transactions that are included in the block.\nI think it has potential for both scaling as well as keeping up a constant\nfee pressure. If tuned properly, it should both stop spamming and increase\nblock size maximum when there are a lot of real transactions waiting for\ninclusion.\n\n- Joel\n\nOn Fri, May 8, 2015 at 1:30 PM, Clément Elbaz \u003cclem.ds at gmail.com\u003e wrote:\n\n\u003e Matt : I think proposal #1 and #3 are a lot better than #2, and #1 is my\n\u003e favorite.\n\u003e\n\u003e I see two problems with proposal #2.\n\u003e The first problem with proposal #2 is that, as we see in democracies,\n\u003e there is often a mismatch between the people conscious vote and these same\n\u003e people behavior.\n\u003e\n\u003e Relying on an intentional vote made consciously by miners by choosing a\n\u003e configuration value can lead to twisted results if their actual behavior\n\u003e doesn't correlate with their vote (eg, they all vote for a small block size\n\u003e because it is the default configuration of their software, and then they\n\u003e fill it completely all the time and everything crashes).\n\u003e\n\u003e The second problem with proposal #2 is that if Gavin and Mike are right,\n\u003e there is simply no time to gather a meaningful amount of votes over the\n\u003e coinbases, after the fork but before the Bitcoin scalability crash.\n\u003e\n\u003e I like proposal #1 because the \"vote\" is made using already available\n\u003e data. Also there is no possible mismatch between behavior and vote. As a\n\u003e miner you vote by choosing to create a big (or small) block, and your\n\u003e actions reflect your vote. It is simple and straightforward.\n\u003e\n\u003e My feelings on proposal #3 is it is a little bit mixing apples and\n\u003e oranges, but I may not seeing all the implications.\n\u003e\n\u003e\n\u003e Le ven. 8 mai 2015 à 09:21, Matt Whitlock \u003cbip at mattwhitlock.name\u003e a\n\u003e écrit :\n\u003e\n\u003e\u003e Between all the flames on this list, several ideas were raised that did\n\u003e\u003e not get much attention. I hereby resubmit these ideas for consideration and\n\u003e\u003e discussion.\n\u003e\u003e\n\u003e\u003e - Perhaps the hard block size limit should be a function of the actual\n\u003e\u003e block sizes over some trailing sampling period. For example, take the\n\u003e\u003e median block size among the most recent 2016 blocks and multiply it by 1.5.\n\u003e\u003e This allows Bitcoin to scale up gradually and organically, rather than\n\u003e\u003e having human beings guessing at what is an appropriate limit.\n\u003e\u003e\n\u003e\u003e - Perhaps the hard block size limit should be determined by a vote of the\n\u003e\u003e miners. Each miner could embed a desired block size limit in the coinbase\n\u003e\u003e transactions of the blocks it publishes. The effective hard block size\n\u003e\u003e limit would be that size having the greatest number of votes within a\n\u003e\u003e sliding window of most recent blocks.\n\u003e\u003e\n\u003e\u003e - Perhaps the hard block size limit should be a function of block-chain\n\u003e\u003e length, so that it can scale up smoothly rather than jumping immediately to\n\u003e\u003e 20 MB. This function could be linear (anticipating a breakdown of Moore's\n\u003e\u003e Law) or quadratic.\n\u003e\u003e\n\u003e\u003e I would be in support of any of the above, but I do not support Mike\n\u003e\u003e Hearn's proposed jump to 20 MB. Hearn's proposal kicks the can down the\n\u003e\u003e road without actually solving the problem, and it does so in a\n\u003e\u003e controversial (step function) way.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\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\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/b6a95d5e/attachment.html\u003e",
"sig": "6d6fd02345ed0ad2dc555a5db73d48eb5895c7c41994403b2f59e394fcb289f0f4e543286a1194fc5f905db8d0b941ff0a22cbee289dab5c26a039d868c0a3a1"
}