From: Gregory Maxwell <gmaxwell@gmail•com>
To: Mike Hearn <hearn@vinumeris•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Date: Tue, 29 Sep 2015 18:31:28 +0000 [thread overview]
Message-ID: <CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com> (raw)
In-Reply-To: <CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
On Mon, Sep 28, 2015 at 10:48 AM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> There is no consensus on using a soft fork to deploy this feature. It will
> result in the same problems as all the other soft forks - SPV wallets will
> become less reliable during the rollout period. I am against that, as it's
> entirely avoidable.
>
> Make it a hard fork and my objection will be dropped.
I'm surprised to see this response-- BIP65 is a year old now which is
plenty of time to mature and for issues to be uncovered. It (and its
predecessors) have had extensive discussion-- with no controversy
exposed during its entire lifetime, but in any case...
I am having a little difficulty making sense of this complaint. For
all any of us know miners are already enforcing the validity of CLTV,
it's indistinguishable on the visible behavior. At the same time in
BitcoinXT's 101 proposal the change in system rules is similarly
"invisible" to existing "SPV" wallets in the same way that enforcement
of CLTV is "invisible": both are no change from their perspective.
Have I missed a proposal to change BIP101 to be a real hardfork (e.g.
be invalid from the perspective of historical bitcoinj clients too)?
---- I'd think it to be completely reasonable to do so, even while not
thinking that it would be reasonable here: Softforks and hardforks
are not the same thing, not technically, and not politically. Miners
can collectively, at their whim, impose any kind of soft fork they
want, at any time and you won't even necessarily be able to tell...
that is just how the system works. Hardforks on the other hand, can
only happen with the consent of the participants-- they can directly
violate system properties that the participants believe to be largely
nonvolatile, and they _force__ software upgrades, so I think having a
higher bar makes good sense there.
The particular mechanism used in the proposal as-is has been used many
times before (and has been refined over time) and we have considerable
experience with it. The behavior is not, in fact, truly invisible to
non-upgraded participants: it's is visible by way of the block version
changing. Bitcoin Core, going back years, responds by issuing a
warning-- "%s: %d of last 100 blocks above version %d\n" which then
becomes "Warning: This version is obsolete; upgrade required!". Users
of the software (directly or via automation) are free to decide to
take whatever policy action they wish to take, delay accepting
transactions, patching software, etc.. The same could be done by any
client of the system if they cared to do so.
I believe the versionbits mechanism will be superior, but-- among
other things-- its deployment has been complicated by BitcoinXT
deploying an incomplete approximation of it. Versionbits primary
advantage is related to having multiple concurrent proposals in
flight, which will be good to have but isn't itself a reason not to
pull a proposal up ahead of versionbits.
next prev parent reply other threads:[~2015-09-29 18:31 UTC|newest]
Thread overview: 101+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-27 18:50 Peter Todd
2015-09-27 20:26 ` jl2012
2015-09-27 20:27 ` Peter Todd
2015-09-27 20:27 ` Mark Friedenbach
2015-09-27 20:41 ` Btc Drak
2015-09-28 10:10 ` s7r
2015-09-28 10:48 ` Mike Hearn
2015-09-28 11:00 ` Adam Back
2015-09-28 11:40 ` Mike Hearn
2015-09-28 12:20 ` Eric Lombrozo
2015-09-28 12:26 ` Mike Hearn
2015-09-28 12:44 ` Eric Lombrozo
2015-09-28 12:54 ` Mike Hearn
2015-09-29 6:17 ` Eric Lombrozo
2015-09-29 12:02 ` Mike Hearn
2015-09-28 14:05 ` Btc Drak
2015-09-28 14:17 ` Mike Hearn
2015-09-28 21:12 ` odinn
2015-09-28 22:16 ` Dave Scotese
2015-09-28 11:04 ` Eric Lombrozo
2015-09-28 12:47 ` Tier Nolan
2015-09-28 13:01 ` Gavin Andresen
2015-09-28 13:28 ` Peter Todd
2015-09-28 13:43 ` Gavin Andresen
2015-09-28 14:14 ` Peter Todd
2015-09-28 13:21 ` Peter Todd
2015-09-28 13:41 ` Mike Hearn
2015-09-28 14:29 ` Peter Todd
2015-09-28 14:33 ` Mike Hearn
2015-09-28 14:43 ` Peter Todd
2015-09-28 14:51 ` Mike Hearn
2015-09-28 15:05 ` Peter Todd
2015-09-28 15:38 ` Mike Hearn
2015-09-28 16:52 ` jl2012
2015-09-28 17:14 ` Mike Hearn
2015-09-28 23:17 ` Jorge Timón
2015-09-29 12:07 ` Mike Hearn
2015-09-29 15:09 ` [bitcoin-dev] Why soft-forks? was: " Santino Napolitano
2015-09-29 13:30 ` [bitcoin-dev] " Jonathan Toomim (Toomim Bros)
2015-09-29 15:59 ` jl2012
2015-09-29 19:54 ` odinn
2015-09-29 18:31 ` Gregory Maxwell [this message]
2015-09-30 17:11 ` Mike Hearn
2015-09-30 17:58 ` Jorge Timón
2015-10-01 14:23 ` Tom Harding
2015-09-30 18:15 ` Adam Back
2015-09-30 19:26 ` Jeff Garzik
2015-09-30 19:56 ` Mike Hearn
2015-09-30 20:37 ` Jorge Timón
2015-09-30 21:06 ` Mike Hearn
2015-09-30 22:14 ` Jorge Timón
2015-10-01 0:11 ` Jorge Timón
2015-09-30 22:17 ` Jeff Garzik
2015-09-30 23:25 ` Gregory Maxwell
2015-09-30 20:15 ` Gregory Maxwell
2015-09-30 21:01 ` Mike Hearn
2015-09-30 22:59 ` Gregory Maxwell
2015-10-01 4:08 ` [bitcoin-dev] Crossing the line? [Was: Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!] Tao Effect
2015-10-01 16:39 ` Jeff Garzik
2015-10-01 20:17 ` Milly Bitcoin
2015-10-02 12:23 ` Mike Hearn
2015-10-02 13:14 ` jl2012
2015-10-02 14:10 ` Marcel Jamin
2015-10-02 16:37 ` Gregory Maxwell
2015-10-07 15:00 ` [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! Anthony Towns
2015-10-07 15:46 ` Jonathan Toomim (Toomim Bros)
2015-10-07 16:02 ` Eric Lombrozo
2015-10-07 16:25 ` Eric Lombrozo
2015-10-07 16:26 ` Jonathan Toomim (Toomim Bros)
2015-10-07 16:38 ` Anthony Towns
2015-10-10 7:23 ` Anthony Towns
2015-10-12 7:02 ` digitsu
2015-10-12 16:33 ` Anthony Towns
2015-10-12 17:06 ` Anthony Towns
2015-10-13 0:08 ` digitsu
2015-09-29 20:03 ` Wladimir J. van der Laan
2015-09-30 4:05 ` Rusty Russell
2015-09-30 6:19 ` Adam Back
2015-09-30 12:30 ` Mike Hearn
2015-09-30 15:55 ` Jorge Timón
2015-09-30 19:17 ` John Winslow
2015-10-01 0:06 ` Rusty Russell
2015-09-30 17:14 ` Adam Back
2015-10-01 0:04 ` Rusty Russell
2015-10-02 1:57 NotMike Hearn
2015-10-02 2:12 ` GC
2015-10-05 10:59 ` Mike Hearn
2015-10-05 11:23 ` Jeff Garzik
2015-10-05 11:28 ` Mike Hearn
2015-10-05 12:04 ` Jorge Timón
2015-10-05 12:08 ` Clément Elbaz
2015-10-05 12:16 ` Jorge Timón
2015-10-05 12:29 ` Clément Elbaz
2015-10-05 15:42 ` Jorge Timón
2015-10-05 12:10 ` Mike Hearn
2015-10-05 15:33 ` Jorge Timón
2015-10-05 16:46 ` Mike Hearn
2015-10-06 6:20 ` Anthony Towns
2015-10-07 6:13 ` Micha Bailey
2015-10-05 13:29 ` Jorge Timón
2015-10-05 13:24 ` Jorge Timón
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='CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=hearn@vinumeris$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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