From: Jonathan Toomim <j@toom.im>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
Date: Sat, 26 Dec 2015 15:07:17 -0800 [thread overview]
Message-ID: <2D7C4E00-7451-45B6-94B6-07A7230FBF88@toom.im> (raw)
In-Reply-To: <CAPg+sBhxnxnQQ-SpWuJ-+_uxRwXkgcU07jkYdZ8BcBwVDyW-vg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 999 bytes --]
On Dec 26, 2015, at 3:01 PM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> I think that's extremely short, even assuming there is no controversy about changing the rules at all. Things like BIP65 and BIP66 already took significantly longer than that, were uncontroversial, and only need miner adoption. Full node adoption is even slower.
>
BIP65 and BIP66 were uncontroversial, but also generally uninteresting. Most people don't care about OP_CLTV right now, and they won't for quite a while longer. They neglect to upgrade their full nodes because there has been no reason to.
Given that a supermajority of users and miners have been asking for a hard fork to increase the blocksize for years, I do not think that mobilizing people to upgrade their nodes is going to be hard.
When we do the hard fork, we will need to encourage people to upgrade their full nodes. We may want to request that miners not trigger the fork until some percentage of visible full nodes have upgraded.
[-- Attachment #1.2: Type: text/html, Size: 1417 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]
next prev parent reply other threads:[~2015-12-26 23:06 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 14:53 [bitcoin-dev] Block size: It's economics & user preparation & moral hazard Jeff Garzik
2015-12-16 18:34 ` Pieter Wuille
2015-12-16 21:08 ` Jeff Garzik
2015-12-16 21:11 ` Pieter Wuille
2015-12-17 2:06 ` Jameson Lopp
2015-12-17 16:58 ` Tier Nolan
2015-12-17 19:44 ` Peter Todd
2015-12-18 5:23 ` Jorge Timón
2015-12-18 9:44 ` Tier Nolan
2015-12-16 21:24 ` Jorge Timón
2015-12-16 21:36 ` Jeff Garzik
2015-12-18 5:11 ` Jeff Garzik
2015-12-18 7:56 ` Pieter Wuille
2015-12-18 10:13 ` sickpig
2015-12-18 15:48 ` Pieter Wuille
2015-12-19 19:04 ` Dave Scotese
[not found] ` <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com>
2015-12-26 16:44 ` Pieter Wuille
2015-12-26 17:20 ` Jorge Timón
2015-12-26 22:55 ` Jonathan Toomim
2015-12-26 23:01 ` Pieter Wuille
2015-12-26 23:07 ` Jonathan Toomim [this message]
2015-12-26 23:16 ` Pieter Wuille
2015-12-27 0:03 ` Jonathan Toomim
2015-12-26 23:15 ` Justus Ranvier
2015-12-27 0:13 ` Bryan Bishop
2015-12-27 0:33 ` Justus Ranvier
2015-12-18 13:56 ` Jeff Garzik
2015-12-23 6:26 ` Aaron Voisine
2015-12-16 18:36 ` jl2012
2015-12-16 22:27 ` Jeff Garzik
2015-12-17 6:12 ` Dave Scotese
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2D7C4E00-7451-45B6-94B6-07A7230FBF88@toom.im \
--to=j@toom.im \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=pieter.wuille@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox