public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <hearn@vinumeris.com>
To: GC <slashdevnull@hotmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Date: Mon, 5 Oct 2015 12:59:54 +0200	[thread overview]
Message-ID: <CA+w+GKT0Th4Tpk=cCxfJwsMdB5NLrARACU3_qiRn4Ns7z_PXYQ@mail.gmail.com> (raw)
In-Reply-To: <BLU436-SMTP132FA09C343ACB7C82E6C98C64B0@phx.gbl>

[-- Attachment #1: Type: text/plain, Size: 3213 bytes --]

Putting aside stupid arguments about who is older or who starting using the
term SPV wallet first, let me try and make a better suggestion than what's
in the BIP. How about the following:

A new flag is introduced to Core, --scriptchecks=[all,standardonly,none].
The default is all. When set to "standardonly", non-standard scripts are
not checked but others are. This is similar to the behaviour during a soft
fork. In "none" you have something a bit like SPV mode, but still
calculating the UTXO set. This flag is simple and can be implemented in a
few lines of code. Then an unused opcode is used for CLTV, so making it a
hard fork.

This has the following advantages:

   - Nodes that want the pseudo-SPV behaviour of a soft fork can opt in to
   it if they want it. This prioritises availability (in a sense) over
   correctness.

   - But otherwise, nodes will prioritise correctness by default, which is
   how it should be. This isn't PHP where nonsensical code the interpreter
   doesn't understand just does ...... something. This is financial software
   where money is at risk. I feel very strongly about this: undefined
   behaviour is fine *if you opted into getting it. *Otherwise it should be
   avoided whenever possible.

   - SPV wallets do the right thing by default.

   - IsStandard doesn't silently become a part of the consensus rules.

   - All other software gets simpler. It's not just SPV wallets. Block
   explorers, for example, can just add a single line to their opcode map.
   With a soft fork they have to implement the entire soft fork logic just to
   figure out when an opcode transitioned from OP_NOP to CLTV and make sure
   they render old scripts differently to new scripts. And they face tricky
   questions - do they render an opcode as a NOP if the miner who built it was
   un-upgraded, or do they calculate the flag day and change all of them after
   that? It's just an explosion of complexity.

Many people by now have accepted that hard forks are simpler, conceptually
cleaner, and prioritise correctness of results over availability of
results. I think these arguments are strong.

So let me try addressing the counter-arguments one more time:

   - Hard forks require everyone to upgrade and soft forks don't. I still
   feel this one has never actually been explained. There is no difference to
   the level of support required to trigger the change. With the suggestion
   above, if someone can't or won't upgrade their full node but can no longer
   verify the change, they can simply restart with -scriptchecks=standardonly
   and get the soft fork behaviour. Or they can upgrade and get their old
   security level back.

   - Hard forks are somehow bad or immoral or can lead to "schisms". This
   is just saying, if we hold a vote, the people who lose the vote might try
   starting a civil war and refuse to accept the change. That's not a reason
   to not hold votes.

   But at any rate, they can do that with soft forks too: just decide that
   any output that contains OP_CLTV doesn't make it into the UTXO set.
   Eventually coins that trace back to such an output will become unusable in
   the section of the economy that decided to pick a fight.

[-- Attachment #2: Type: text/html, Size: 3446 bytes --]

  reply	other threads:[~2015-10-05 10:59 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-02  1:57 [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY! NotMike Hearn
2015-10-02  2:12 ` GC
2015-10-05 10:59   ` Mike Hearn [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
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 13:30             ` 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-07 15:00     ` 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

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+GKT0Th4Tpk=cCxfJwsMdB5NLrARACU3_qiRn4Ns7z_PXYQ@mail.gmail.com' \
    --to=hearn@vinumeris.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=slashdevnull@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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