From: Mike Hearn <hearn@vinumeris•com>
To: Peter Todd <pete@petertodd•org>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Date: Mon, 28 Sep 2015 17:38:28 +0200 [thread overview]
Message-ID: <CA+w+GKTPKxGWWN28_hzR8BoCh11exvgZm4s-_=5oFWd-R62uyA@mail.gmail.com> (raw)
In-Reply-To: <20150928150543.GB28939@savin.petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]
>
> Can you explain exactly how you think wallets will "know" how to ignore
> the invalid chain?
>
I'm confused - I already said this. For a fork to work, hard or soft, there
must be support from a majority of the hash power.
Therefore, the usual SPV technique of following the highest work chain
results in ignoring the minority chain produced by the hard fork.
BIP 101 is SPV friendly because the wallets would simply follow the 75%
chain and never even be aware anything has changed. It's backwards
compatible with them in this respect: they already know how to ignore the
no-bigger-blocks fork that'd be created if some miners didn't upgrade
during the grace period.
My point about IsStandard is that miners can and do bypass it, without
expecting that to carry financial consequences or lower the security of
other users. By making it so a block which includes non-standard
transactions can end up being seen as invalid, you are increasing the risk
of accidents that carry financial consequences.
That's incorrect: Miners bypassing IsStandard() risk creating invalid
> blocks in the event of a soft-fork. Equally, we design soft-forks to
> take advantage of this.
>
Gah. You repeated what I just said. Yes, I know miners face that risk, my
point is that they do NOT face such a risk when there's no soft fork in
action and have historically NOT faced that risk at all, hence the
widespread practice of bypassing or modifying this function.
All this approach does is make changing IsStandard() the same as changing
AcceptBlock(), except without the advantage of telling anyone about it.
> > So I'll repeat the question that I posed before - given that there are
> > clear, explicit downsides, what is the purpose of doing things this way?
> > Where is the gain for ordinary Bitcoin users?
>
> We seem to be in strong disagreement about which option has "clear,
> explicit downsides"
Obviously. So please enlighten me.
How do ordinary Bitcoin users benefit from this rollout strategy? Put
simply, what is the point of this whole complex soft fork endeavour?
[-- Attachment #2: Type: text/html, Size: 2818 bytes --]
next prev parent reply other threads:[~2015-09-28 15:38 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 [this message]
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
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='CA+w+GKTPKxGWWN28_hzR8BoCh11exvgZm4s-_=5oFWd-R62uyA@mail.gmail.com' \
--to=hearn@vinumeris$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/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