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.
next prev parent 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 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$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=praxeology_guy@protonmail$(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