public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <hearn@vinumeris.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: Mon, 5 Oct 2015 13:28:13 +0200	[thread overview]
Message-ID: <CA+w+GKTkos5gwZmN_1c7wUFmJgZMJGzZbaZeWO=Rwt3Ta3Zbzw@mail.gmail.com> (raw)
In-Reply-To: <CADm_WcaVbj98G9acqbwUxYudHhWh01FLpm5KgL3rqHffd5WCXg@mail.gmail.com>

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

Well, let's agree to disagree on these two things:

- I define "working" for a full node as verifying everything; if a node
starts skipping bits then I'd say it's not really "working" according to
its original design goals

- Saying the pre-fork behaviour is defined and deterministic is true, but
only in the sense that reading an uninitialised variable in C is defined
and deterministic. It reads whatever happens to be at that stack position:
easily defined. For many programs, that may be the same value each time:
deterministic. Nonetheless, it's considered undefined behaviour by the C
specification and programmers that rely on it can easily create security
holes.

In the same way, I'd consider a node running a script with a NOP and
reaching the opposite conclusion from other nodes to be a case of undefined
behaviour leading to a non-fully-working node.

But these are arguments about the semantics of words. I think we both know
what each other is getting at.

On Mon, Oct 5, 2015 at 1:23 PM, Jeff Garzik <jgarzik@gmail.com> wrote:

>
> - It is true that hard forks produce a much cleaner outcome, in terms of
> well defined behavior across the entire network.
>
> - Replacing an opcode should not result in undefined behavior.  The
> non-upgraded behavior is defined and deterministic.
>
> - IsStandard remains an assistant.  Miners may mine non-standard
> transactions.
>
> - "Hard forks require everyone to upgrade and soft forks don't"   Doesn't
> require tons of explanation:  Non upgraded clients continue working on the
> network even after the rules are upgraded.
>
> All those corrections aside, I do think there has been too much hysteria
> surrounding hard forks.  Hard forks, when done right, produce a much
> cleaner system for users.
>
>
>
>
>
>
>
>
> On Mon, Oct 5, 2015 at 6:59 AM, Mike Hearn via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 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.
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>

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

  reply	other threads:[~2015-10-05 11:28 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
2015-10-05 11:23     ` Jeff Garzik
2015-10-05 11:28       ` Mike Hearn [this message]
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+GKTkos5gwZmN_1c7wUFmJgZMJGzZbaZeWO=Rwt3Ta3Zbzw@mail.gmail.com' \
    --to=hearn@vinumeris.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jgarzik@gmail.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