From: "Jorge Timón" <jtimon@jtimon•cc>
To: Mike Hearn <hearn@vinumeris•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Date: Wed, 30 Sep 2015 19:58:45 +0200 [thread overview]
Message-ID: <CABm2gDrkv3T66=BCBiHYb9h8PY41TFCwpzVR_E7UM0c+QcK-Eg@mail.gmail.com> (raw)
In-Reply-To: <CA+w+GKRKGS=KZrLtiW8Zbn4EQH_TELfQR+TfrADCMXLR22Q+tw@mail.gmail.com>
On Wed, Sep 30, 2015 at 7:11 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Several people have asked several times now: given the very real and widely
> acknowledged downsides that come with a soft fork, what is the specific
> benefit to end users of doing them?
As previously explained, the biggest advantage of softforks is that
assuming the hasrate majority upgrades, network convergence is
guaranteed.
I don't know of anyone else (apart from you) that believes that the
advantages of softforks are generally worse than those of hardforks.
I'm attempting to clarify everything related to consensus rule changes
in BIP99.
> Until that question is answered to my satisfaction I continue to object to
> this BIP on the grounds that the deployment creates financial risk
> unnecessarily. To repeat: CLTV does not have consensus at the moment.
But your argument is flawed because it assumes softforks are more
risky than hardforks.
You've been explained why this is not the case, so unless you can
explain what's more important for a consensus system than network
convergence I think we can still consider this consensus rule change
uncontroversial, just like BIP66 was (even if you were also unable to
understand the advantages of softforks back then, just like you are
unable to understand them now, as you just proved in your answer to my
explanation). Using BIP99's terminology, this is an "uncontroversial
softfork" and it's therefore the safest option for consensus rule
changes deployment.
I should definitely improve my explanation on why uncontroversial
softforks are preferrable to uncontroversial hardforks in most cases
(and maybe try to come up with an example in which a hardfork is
preferable). I should also explain the disadvantages of
uncontroversial softforks that you have pointed out several times. So
I will mention you in BIP99's PR once I update it with a new section
that talks about the trade offs of uncontroversial softforks vs
uncontroversial hardforks.
In the meantime I believe that we can safely move forwards with BIP65
(again, just like we did with BIP66 ) and I also believe that you, as
an expert in Bitcoin, will eventually be able to understand the
advantages of uncontroversial softforks.
With all due respect, I don't think we need to wait for you to
understand the advantages of softforks to move forward with BIP65,
just like we didn't need to wait for every developer and user to
understand BIP66 to deploy it.
You don't have specific complaints against the new script operator,
and you don't have an uncontroversial hardfork alternative design (or
implementation).
This is a feature that enables new contracts that are important to
Bitcoin. Please don't try to block it just to make a point about what
"uncontroversial" means.
next prev parent reply other threads:[~2015-09-30 17:58 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
2015-09-30 17:11 ` Mike Hearn
2015-09-30 17:58 ` Jorge Timón [this message]
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='CABm2gDrkv3T66=BCBiHYb9h8PY41TFCwpzVR_E7UM0c+QcK-Eg@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--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