From: Anthony Towns <aj@erisian•com.au>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Date: Thu, 8 Oct 2015 01:00:14 +1000 [thread overview]
Message-ID: <20151007150014.GA21849@navy> (raw)
In-Reply-To: <CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
On Tue, Sep 29, 2015 at 06:31:28PM +0000, Gregory Maxwell via bitcoin-dev wrote:
> 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-- [...]
> I am having a little difficulty making sense of this complaint. [...]
I think I finally understand this objection.
For a hard fork, activated by a majority of nodes/hashpower upgrading
to a new bitcoin release, the behaviour is:
- upgraded bitcoin nodes: everything works fine
- non-upgraded bitcoin nodes: total breakage. there will be a push
alert telling you to upgrade. anyone who doesn't will think they're
tracking "bitcoin" but will actually be tracking a new "bitcoin-old"
altcoin. most non-upgraded miners will presumably realise they're
wasting hashpower and stop doing this pretty quick; and remaining
miners will only create blocks very slowly due to sudden reduced
hashpower, without possibility of difficulty adjustment. users who
don't uprade will try to do transactions, but won't see them confirm
for hours or days due to lack of hashpower.
- SPV nodes: they track the upgraded majority, everything works fine
even if they don't upgrade
For a soft fork, again activated by the majority of upgraded hashpower,
the behaviour is:
- upgraded bitcoin nodes: everything works fine
- non-upgraded bitcoin miners willing to mine newly unacceptable txs:
may produce orphaned blocks; may be able to be forced into producing
blocks that will be orphaned
- other non-upgraded bitcoin nodes: everything works fine
- SPV nodes: partial breakage -- may track invalid blocks for 1-2
confirmations until the set of "non-upgraded bitcoin miners willing
to produce newly unacceptable txs" becomes vanishingly few.
In the hard fork case, all non-upgraded nodes get a DoS attack, but
aren't likey to be hit by doublespends. That's inconvenient, but it's
not too bad.
In the soft fork case, if there's likely to be old nodes mining
previously invalid transactions, SPV clients become very unreliable,
to the point of possibly seeing semi-regular double-spends with 1 or
2 confirmation, until miners that aren't paying attention notice their
blocks are getting orphaned and upgrade. That is pretty bad IMHO; and
there are a lot more *people* running SPV clients than bitcoin nodes,
so its impact is potentially worse in both ways.
Comparing generic hard forks versus generic soft forks, the above says
to me that a hard fork would be less harmful to users in general, and
thus a better approach.
*But* a soft fork that only forbids transactions that would previously
not have been mined anyway should be the best of both worlds, as it
automatically reduces the liklihood of old miners building newly invalid
blocks to a vanishingly small probability; which means that upgraded
bitcoin nodes, non-upgraded bitcoin nodes, /and/ SPV clients *all*
continuing to work fine during the upgrade.
AFAICS, that's what BIP65 achieves, as will similar OP_NOP* replacements
like BIP112.
But that only applies to a subset of potential soft forks, not every
soft fork.
Maybe a good way to think about it is something like this. Consensus
(IsValid) is always less restrictive than (default) policy (previously
IsStandard, not sure how to summarise it now, maybe it's just OP_NOP
redefinition?). So choosing a new consensus rule will be one of:
* even less restrictive than consensus (hard fork)
* more restrictive than consensus, but less restrictive than policy
(safe soft fork)
* more restrictive than IsStandard etc (damaging soft fork)
Hmm, in particular, following this line of thinking it's not clear to
me that BIP68 is actually less restrictive than current policy? At
least, I can't see anything that prevents txs with nSequence set to
something other than 0 or ~0 from being relayed?
If it's not, and nodes currently happily mine and relay transactions
with nSequence set without caring what it's set to, doesn't this mean
BIP68 is of the "damaging soft fork" variety? That is, if it activated
as a soft-fork with a majority of miners using it, but a minority of ~5%
not upgraded, then
- someone could construct an tx with nSequence set to sometime in
the future, but not using OP_CSV
- this tx would get relayed by old nodes (but not upgraded nodes
due to CheckLockTime)
- non-upgraded miners would mine it into a block immediately, which
would then get orphaned by majority hashpower
- before it got orphaned, non-upgraded nodes and SPV clients would
be misled and vulnerable to double spend attacks of txs with 0, 1 or
maybe 2 confirmations
(BIP65 with OP_CLTV and BIP112 with OP_CSV don't have that problem as
they both redefine a non-standard opcode and would not get relayed or
mined by old, non-upgraded nodes, and are thus "safe soft forks" per
above terminology. This is just BIP68)
Can anyone confirm or refute the above?
Cheers,
aj
next prev parent reply other threads:[~2015-10-07 15:00 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 ` Anthony Towns [this message]
2015-10-07 15:46 ` [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! 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=20151007150014.GA21849@navy \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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