From: Gregory Maxwell <gmaxwell@gmail•com>
To: Jeff Garzik <jgarzik@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Date: Wed, 30 Sep 2015 23:25:03 +0000 [thread overview]
Message-ID: <CAAS2fgTOSiTeY3=qprRGdQUVvr60JjJjP2SPvVFtRGrQGHL8Vw@mail.gmail.com> (raw)
In-Reply-To: <CADm_WcZpdpnov5Tiz3_3gpUyDz=rTkKKvYexBzcFLcHKDUdxJQ@mail.gmail.com>
On Wed, Sep 30, 2015 at 10:17 PM, Jeff Garzik <jgarzik@gmail•com> wrote:
> It is correct that security is slightly reduced for full nodes that have not
> upgraded. It is not correct that the choice is binary, full node or SPV.
>
> Any user running a not-upgraded full node still retains protection against
> many attacks outside the subset related to the feature being introduced.
An extra way to look at this is that even absent any rule changes--
users who are asleep at the switch may lose effective security over
time because attackers learn new tricks against existing
vulnerabilities. Security requires a bit of vigilance, inherently.
In many specific cases I think it's hard-to-impossible to articulate a
concrete way that security is lost by users at all, excluding some
small amplification of orphan blocks.
On Wed, Sep 30, 2015 at 9:06 PM, Mike Hearn via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> and is trying to mine it, will keep producing invalid blocks forever until
> the owner shuts it down and upgrades.
This is the outcome guaranteed for absentee miners with a hard fork,
but it is not guaranteed for a soft fork.
> For instance, any miner that has modified/bypassed IsStandard() can do this,
Miners who have changed their code in inadvisable ways can produce
invalid blocks as a result. There are many seemingly innocuous ways
one can produce invalid blocks, and miners have stumbled on a few of
them over the years.
Pedantically, modifying IsStandard() will not have this effect:
Unknown NOPs are now handled via a script validation flag--
SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS. Experience (e.g. with
STRICTDER) has show that script validation flags are much more robust
to casual twiddling than IsStandard is.
The only way that script validation flags have been observed getting
bypassed in the field was a miner that had disabled all signature
validation completely (and whom had a not-completely-negligible amount
of hashpower. :( )... as it's a lot more clear that you might be
exposing yourself to trouble if you mess with the validation flags.
> runs an old node from before OP_NOPs were made non-standard.
IIRC; There is no released version of Bitcoin that has IsStandard
which has failed failed to treat the NOPs as non-standard.
There was a brief time in git master between when IsStandardness was
relaxed and NOPs were addressed via a validation flag but I am
reasonably confident that didn't make it into a release.
Regardless, anyone actually running that code of that vintage would
already be incompatible with the current network already due to prior
soft forks.
And as a matter of fact, invalid CLTVs don't currently appear to get
mined. Checking this again pre-release would be a good checklist item.
For prior soft-forks we've monitored and tested for this (with the
goal of going and yelling at any broken miners to fix their behavior).
next prev parent reply other threads:[~2015-09-30 23:25 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 [this message]
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='CAAS2fgTOSiTeY3=qprRGdQUVvr60JjJjP2SPvVFtRGrQGHL8Vw@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jgarzik@gmail$(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