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

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

Ryan Grant,

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.

Does BIP9 work with hard forks? Pretty sure it is only for soft forks. If you want to make a hard fork, there is not much point in waiting for any particular miner hash power adoption rate.

With a softfork, here is the only condition for a "stopped chain":
1. User adopts more stringent rules.
2. Someone maliciously creates an invalid block as evaluated by the more stringent rules in #1, but that is valid to older nodes
3. No one ever mines a different block at the height of the block in #2, instead all of the miners only build on top of the block built at #2.

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).

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. Such an event could be an excellent trigger to enable replay attack prevention, although maybe not automatically... unless everyone was pretty sure that a long-standing competing fork was likely to occur.

Cheers,
Praxeology Guy

-------- Original Message --------
Subject: Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in
Local Time: April 7, 2017 8:55 AM
UTC Time: April 7, 2017 1:55 PM
From: bitcoin-dev@lists.linuxfoundation.org
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>

The primary failure mode of a user's misconfiguration of nTimeout will
be a stopped chain.

If less-sophisticated users are offered these configuration settings
then chaintip progress failures that result from them should be
prominently displayed.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

  reply	other threads:[~2017-04-07 17:57 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 [this message]
2017-04-08  4:48       ` Ryan Grant
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='6aTsiLggIIoxf0V0RsV1i0B_DLZasJBjUdTTQewxIZYLFHvDVv3sRCFQBNCZ91gkin6vBi_AJgYZ1tVfsnigSAo8JOvDEcQCn7eRbfeH-CA=@protonmail.com' \
    --to=praxeology_guy@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=bitcoin-dev@rgrant.org \
    /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