public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ryan Grant <bitcoin-dev@rgrant.org>
To: praxeology_guy <praxeology_guy@protonmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in
Date: Fri, 7 Apr 2017 23:48:34 -0500	[thread overview]
Message-ID: <CAMnpzfpMdikBvoJcQriS6487LmFPB4cxtVj+kQGmqhoOMfyjQg@mail.gmail.com> (raw)
In-Reply-To: <6aTsiLggIIoxf0V0RsV1i0B_DLZasJBjUdTTQewxIZYLFHvDVv3sRCFQBNCZ91gkin6vBi_AJgYZ1tVfsnigSAo8JOvDEcQCn7eRbfeH-CA=@protonmail.com>

Praxeology Guy,

On Fri, Apr 7, 2017 at 12:56 PM, praxeology_guy
<praxeology_guy@protonmail.com> wrote:
> TLDR Unless I'm missing something, your claim that a
> misconfiguration would result in a stop chain is wrong because BIP9
> only works on soft forks.

If our rule change timing is different from changes on the chain with
most work, then (extending Johnson Lau's terminology a bit) we may
experience subjective hardfork-ness; due to miners creating blocks
which the economic majority goes on to accept, though they have a less
restrictive ruleset than ours.

> The user would have to adopt a soft fork at a time where no miner
> has also done the same, and where someone creates a contradictory
> block (which normally wouldn't happen unless someone was being
> malicious).

Correct for the segwit soft fork, which is narrowing the definition
of a nonstandard transaction.  It's safe to say that if a block with a
tx violating cleanstack were to occur on a non-segwit chain, that it
was for malicious reasons.

However, some future forks - that a full node experiences as
low subjective hardfork-ness (i.e. soft forks) - might restrict
more common things.

> Never the less, I kind of like the idea of the user being notified
> when a newly activated more stringent soft fork rule caused a block
> to be rejected.  The first time it happens, a message could come up,
> and then for some time after maybe it would be logged somewhere
> easily accessible.

Sure, a nice-to-have would be a SetfLargeWorkInvalidChainFound() that
was aware as well, though clients can make these decisions themselves.


  reply	other threads:[~2017-04-08  4:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-06 21:25 [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in shaolinfry
2017-04-07  8:38 ` praxeology_guy
2017-04-07 13:55   ` Ryan Grant
2017-04-07 17:56     ` praxeology_guy
2017-04-08  4:48       ` Ryan Grant [this message]
2017-04-18 12:37 Kekcoin

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=CAMnpzfpMdikBvoJcQriS6487LmFPB4cxtVj+kQGmqhoOMfyjQg@mail.gmail.com \
    --to=bitcoin-dev@rgrant.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=praxeology_guy@protonmail.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