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 17:55:52 +0200 [thread overview]
Message-ID: <CABm2gDqkTizK1TtGGM4fFp4xWMUhAstVOvnJ4_3VKaGNoSX0eg@mail.gmail.com> (raw)
In-Reply-To: <CA+w+GKRd69kOiDKE_56vnbZ=Hx4hhXqtzpsVT6Z+fx005zW_MQ@mail.gmail.com>
On Tue, Sep 29, 2015 at 2:07 PM, Mike Hearn <hearn@vinumeris•com> wrote:
> Hi Jorge,
>
>> Yes, there is a difference. Assuming the hashrate majority upgrades, in
>> the case of a softfork [snip] ...... In the case of a hardfork [snip]
>
> Yes, I know what the difference between them is at a technical level. You
> didn't explain why this would make any difference to how fast miners
> upgrade. The amount of money they lose in both cases is identical: they are
> equally incentivised to upgrade with both fork types.
>
> Additionally, you say in a hard fork the other chain may "continue forever".
> Why do you think this is not true for miners building invalid blocks on top
> of the main chain? Why would that not continue forever?
I didn't talked about how fast miners would upgrade, please read again
because I believe I was extremely precise.
In both cases I'm assuming there's a minority of the hasrate which
doesn't upgrade.
In the softfork case, the minority will always build on top of the
longest chain (which is valid to them). There may be many little
alternative chains that are ignored (and orphaned) by the upgraded
miners, but non-upgraded miners will always build on top of the
longest chain.
In the hardfork case, non-upgraded miners will reject the upgraded
chain because it is invalid to them, so they will build on top of the
longest non-upgraded chains.
Two alternative chains will continue growing forever unless the
non-upgraded miners eventually upgrade.
In contrast, there won't be 2 alternative chains growing forever in
the softfork case even if the minority miners never upgrade.
> There just isn't any difference between the two fork types in terms of how
> fast miners would upgrade. Heck if anything, a hard fork should promote
> faster upgrades, because if a miner isn't paying attention to their
> debug.log they might miss the warnings. A soft fork would then look
> identical to a run of really bad luck, which can legitimately happen from
> time to time. A hard fork results in your node having a different height to
> everyone else, which is easily detectable by just checking a block explorer.
>>
>> This discussion about the general desirability of softforks seems offtopic
>> for the concrete cltv deployment discussion, which assumes softforks as
>> deployment mechanism (just like bip66 assumed it).
>
> Isn't that circular? This thread is about deployment of CLTV, but the BIP
> assumes a particular mechanism, so pointing out problems with it is off
> topic? Why have a thread at all?
BIP99 recommends an uncontroversial softfork for this kind of case.
You seem to be contradicting BIP99 in many other places. Maybe you
want to complain about some of the recommendations in BIP99 (instead
of everywhere else):
https://github.com/bitcoin/bips/pull/181
On Wed, Sep 30, 2015 at 2:30 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> This will not change the fact that the rollout strategy is bad and nobody
> has answered my extremely basic question: why is it being done in this way,
> given the numerous downsides?
You seem to be the only one who thinks that softforks have "numerous
downsides" over hardforks.
So everybody just basically disagrees with the assumption in your
question and thus nobody can answer it.
next prev parent reply other threads:[~2015-09-30 15:55 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
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 [this message]
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=CABm2gDqkTizK1TtGGM4fFp4xWMUhAstVOvnJ4_3VKaGNoSX0eg@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