Joel Joonatan Kaartinen [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-08 📝 Original message:Matt, It seems you missed ...
📅 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>;
📝 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>;