Yifu Guo [ARCHIVE] on Nostr: đ Original date posted:2016-02-05 đ Original message:"We can look at the ...
đ
Original date posted:2016-02-05
đ Original message:"We can look at the adoption of the last major Bitcoin core release to
guess how long it might take people to upgrade. 0.11.0 was released on 12
July, 2015. Twenty eight days later, about 38% of full nodes were running
that release. Three months later, about 50% of the network was running that
release, and six months later about 66% of the network was running some
flavor of 0.11."
On what grounds do you think it is reasonable to assume that this update
will roll out 6x faster than previous data suggested, as oppose to your own
observation of 66% adoption in 6 month. or do you believe 38% node
upgrade-coverage ( in 28 days ) on the network for a hard fork is good
enough?
There are no harm in choosing a longer grace period but picking one short
as 28 days you risk on alienating the nodes who do not upgrade with the
aggressive upgrade timeline you proposed.
On Fri, Feb 5, 2016 at 3:51 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This has been reviewed by merchants, miners and exchanges for a couple of
> weeks, and has been implemented and tested as part of the Bitcoin Classic
> and Bitcoin XT implementations.
>
> Constructive feedback welcome; argument about whether or not it is a good
> idea to roll out a hard fork now will be unproductive, so I vote we don't
> go there.
>
> Draft BIP:
> https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki
>
> Summary:
> Increase block size limit to 2,000,000 bytes.
> After 75% hashpower support then 28-day grace period.
> With accurate sigop counting, but existing sigop limit (20,000)
> And a new, high limit on signature hashing
>
> Blog post walking through the code:
> http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
>
> Blog post on a couple of the constants chosen:
> http://gavinandresen.ninja/seventyfive-twentyeight
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
*Yifu Guo*
*"Life is an everlasting self-improvement."*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160205/e9662b77/attachment.html>;
đ Original message:"We can look at the adoption of the last major Bitcoin core release to
guess how long it might take people to upgrade. 0.11.0 was released on 12
July, 2015. Twenty eight days later, about 38% of full nodes were running
that release. Three months later, about 50% of the network was running that
release, and six months later about 66% of the network was running some
flavor of 0.11."
On what grounds do you think it is reasonable to assume that this update
will roll out 6x faster than previous data suggested, as oppose to your own
observation of 66% adoption in 6 month. or do you believe 38% node
upgrade-coverage ( in 28 days ) on the network for a hard fork is good
enough?
There are no harm in choosing a longer grace period but picking one short
as 28 days you risk on alienating the nodes who do not upgrade with the
aggressive upgrade timeline you proposed.
On Fri, Feb 5, 2016 at 3:51 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This has been reviewed by merchants, miners and exchanges for a couple of
> weeks, and has been implemented and tested as part of the Bitcoin Classic
> and Bitcoin XT implementations.
>
> Constructive feedback welcome; argument about whether or not it is a good
> idea to roll out a hard fork now will be unproductive, so I vote we don't
> go there.
>
> Draft BIP:
> https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki
>
> Summary:
> Increase block size limit to 2,000,000 bytes.
> After 75% hashpower support then 28-day grace period.
> With accurate sigop counting, but existing sigop limit (20,000)
> And a new, high limit on signature hashing
>
> Blog post walking through the code:
> http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
>
> Blog post on a couple of the constants chosen:
> http://gavinandresen.ninja/seventyfive-twentyeight
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
*Yifu Guo*
*"Life is an everlasting self-improvement."*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160205/e9662b77/attachment.html>;