Admin Istrator [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-29 📝 Original message:What about trying the ...
📅 Original date posted:2015-05-29
📝 Original message:What about trying the dynamic scaling method within the 20MB range + 1 year
with a 40% increase of that cap? Until a way to dynamically scale is
found, the cap will only continue to be an issue. With 20 MB + 40% yoy,
we're either imposing an arbitrary cap later, or achieving less than great
DOS protection always. Why not set that policy as a maximum for 2 years as
a protection against the possibility of dynamic scaling abuse, and see what
happens with a dynamic method in the mean time. The policy of Max(1MB,
(average size over previous 144 blocks) * 2) calculated at each block seems
pretty reasonable.
As an outsider, the real 'median' here seems to be 'keeping the cap as
small as possible while allowing for larger blocks still'. We know
miners will want to keep space in their blocks relatively scarce, but we
also know that doesn't exclude the more powerful miners from
including superfluous transactions to increase their effective share of the
network. I have the luck of not being drained by this topic over the past
three years, so it looks to me as if its two poles of 'block size must
increase' and 'block size must not increase' are forcing what is the clear
route to establishing the 'right' block size off the table.
--Andrew Len
(sorry if anybody received this twice, sent as the wrong email the first
time around).
On Fri, May 29, 2015 at 5:39 AM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> What do other people think?
>
>
> If we can't come to an agreement soon, then I'll ask for help
> reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
> big increase now that grows over time so we may never have to go through
> all this rancor and debate again.
>
> I'll then ask for help lobbying the merchant services and exchanges and
> hosted wallet companies and other bitcoind-using-infrastructure companies
> (and anybody who agrees with me that we need bigger blocks sooner rather
> than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they
> are running it. We'll be able to see uptake on the network by monitoring
> client versions.
>
> Perhaps by the time that happens there will be consensus bigger blocks are
> needed sooner rather than later; if so, great! The early deployment will
> just serve as early testing, and all of the software already deployed will
> ready for bigger blocks.
>
> But if there is still no consensus among developers but the "bigger blocks
> now" movement is successful, I'll ask for help getting big miners to do the
> same, and use the soft-fork block version voting mechanism to (hopefully)
> get a majority and then a super-majority willing to produce bigger blocks.
> The purpose of that process is to prove to any doubters that they'd better
> start supporting bigger blocks or they'll be left behind, and to give them
> a chance to upgrade before that happens.
>
>
> Because if we can't come to consensus here, the ultimate authority for
> determining consensus is what code the majority of merchants and exchanges
> and miners are running.
>
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150529/3d4a11fb/attachment.html>;
📝 Original message:What about trying the dynamic scaling method within the 20MB range + 1 year
with a 40% increase of that cap? Until a way to dynamically scale is
found, the cap will only continue to be an issue. With 20 MB + 40% yoy,
we're either imposing an arbitrary cap later, or achieving less than great
DOS protection always. Why not set that policy as a maximum for 2 years as
a protection against the possibility of dynamic scaling abuse, and see what
happens with a dynamic method in the mean time. The policy of Max(1MB,
(average size over previous 144 blocks) * 2) calculated at each block seems
pretty reasonable.
As an outsider, the real 'median' here seems to be 'keeping the cap as
small as possible while allowing for larger blocks still'. We know
miners will want to keep space in their blocks relatively scarce, but we
also know that doesn't exclude the more powerful miners from
including superfluous transactions to increase their effective share of the
network. I have the luck of not being drained by this topic over the past
three years, so it looks to me as if its two poles of 'block size must
increase' and 'block size must not increase' are forcing what is the clear
route to establishing the 'right' block size off the table.
--Andrew Len
(sorry if anybody received this twice, sent as the wrong email the first
time around).
On Fri, May 29, 2015 at 5:39 AM, Gavin Andresen <gavinandresen at gmail.com>
wrote:
> What do other people think?
>
>
> If we can't come to an agreement soon, then I'll ask for help
> reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
> big increase now that grows over time so we may never have to go through
> all this rancor and debate again.
>
> I'll then ask for help lobbying the merchant services and exchanges and
> hosted wallet companies and other bitcoind-using-infrastructure companies
> (and anybody who agrees with me that we need bigger blocks sooner rather
> than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they
> are running it. We'll be able to see uptake on the network by monitoring
> client versions.
>
> Perhaps by the time that happens there will be consensus bigger blocks are
> needed sooner rather than later; if so, great! The early deployment will
> just serve as early testing, and all of the software already deployed will
> ready for bigger blocks.
>
> But if there is still no consensus among developers but the "bigger blocks
> now" movement is successful, I'll ask for help getting big miners to do the
> same, and use the soft-fork block version voting mechanism to (hopefully)
> get a majority and then a super-majority willing to produce bigger blocks.
> The purpose of that process is to prove to any doubters that they'd better
> start supporting bigger blocks or they'll be left behind, and to give them
> a chance to upgrade before that happens.
>
>
> Because if we can't come to consensus here, the ultimate authority for
> determining consensus is what code the majority of merchants and exchanges
> and miners are running.
>
>
> --
> --
> Gavin Andresen
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150529/3d4a11fb/attachment.html>;