Justus Ranvier [ARCHIVE] on Nostr: š Original date posted:2015-12-26 š Original message:On 12/26/2015 05:01 PM, ...
š
Original date posted:2015-12-26
š Original message:On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote:
> I think the shortest reasonable timeframe for an uncontroversial
> hardfork is somewhere in the range between 6 and 12 months.
This argument would hold more weight if it didn't looks like a stalling
tactic in context.
6 months ago, there was a concerted effort to being the process then,
for exactly this reason.
After 6 months of denial, stonewalling, and generally unproductive
fighting, the need for proactivity is being acknowledged with no
reference to the delay.
If the network ever ends up making a hasty forced upgrade to solve a
capacity emergency the responsibility for that difficulty will not fall
on those who did their best to prevent emergency upgrades by planning ahead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/218f1c1b/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/218f1c1b/attachment-0001.sig>
š Original message:On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote:
> I think the shortest reasonable timeframe for an uncontroversial
> hardfork is somewhere in the range between 6 and 12 months.
This argument would hold more weight if it didn't looks like a stalling
tactic in context.
6 months ago, there was a concerted effort to being the process then,
for exactly this reason.
After 6 months of denial, stonewalling, and generally unproductive
fighting, the need for proactivity is being acknowledged with no
reference to the delay.
If the network ever ends up making a hasty forced upgrade to solve a
capacity emergency the responsibility for that difficulty will not fall
on those who did their best to prevent emergency upgrades by planning ahead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/218f1c1b/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151226/218f1c1b/attachment-0001.sig>