public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Kekcoin <kekcoin@protonmail.com>
To: Gregory Maxwell <greg@xiph.org>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Height based vs block time based thresholds
Date: Wed, 05 Jul 2017 04:54:40 -0400	[thread overview]
Message-ID: <akYjeiyeQP1gBjSOYOIbtnvgWVWjElJ065jNlZsDlbQ0TXoBlP9iJx2p9jOI4pKG5ltmPJsDPJ--rs8ruts6AiOgwZ-_dIfkT6b7hJwFb8A=@protonmail.com> (raw)
In-Reply-To: <CAAS2fgTko+aszOReFX5Svo4h-qROzdU9+vZLSDoR97do6YJ_cQ@mail.gmail.com>

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

Luke's proposed changes to BIP8 (specifically, the FAILING state) seem designed to address the regression compared to BIP9 that there is no way to avoid activating a softfork that is shown to be suboptimal or flawed in some (serious enough) way - after deployment is well underway - without hardforking.
I agree with your principle but we should also look at the circumstances in which this mechanism would be beneficial vs. when it would cause harm (compared to BIP8 without this mechanism). The scenario this was designed for is "miners refusing to activate, on non-technical grounds, a widely desired upgrade" - in which case the "wakeup call" would be in users' hands, not anyone in particular.
Is there a hypothetical scenario in which the orphan risk outweighs the benefits of having this kind of upgrade mechanism that can (at deploy-time) be chosen to be optional by default with a deferred mechanism to make it mandatory? If so, is there any thought on how to realize the latter without the former?

Sent with [ProtonMail](https://protonmail.com) Secure Email.

> -------- Original Message --------
> Subject: Re: [bitcoin-dev] Height based vs block time based thresholds
> Local Time: July 5, 2017 8:06 AM
> UTC Time: July 5, 2017 8:06 AM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
> On Wed, Jul 5, 2017 at 3:50 AM, Luke Dashjr via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> I"ve already opened a PR almost 2 weeks ago to do this and fix the other
>> issues BIP 9 has. https://github.com/bitcoin/bips/pull/550
>>
>> It just needs your ACK to merge.
> These proposals for gratuitous orphaning are reckless and coersive.
> We have a professional obligation to first do no harm, and amplifying
> orphaning which can otherwise easily be avoided violates it.
> It is not anyones position to decide who does and doesn"t need to be
> "woken up" with avoidable finical harm, nor is it any of our right to
> do so at the risk of monetary losses by any and all users users from
> the resulting network instability.
> It"s one thing to argue that some disruption is strictly needed for
> the sake of advancement, it"s another to see yourself fit as judge,
> jury, and executioner to any that does not jump at your command.
> (which is exactly the tone I and at least some others extract from
> your advocacy of these changes and similar activity around BIP148).
> I for one oppose those changes strongly.
>> Not having a mandatory signal turned out to be a serious bug in BIP 9,
> I have seen no evidence or case for this.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

  reply	other threads:[~2017-07-05  8:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-05  1:30 [bitcoin-dev] Height based vs block time based thresholds shaolinfry
2017-07-05  2:25 ` Troy Benjegerdes
2017-07-05  3:39 ` Bram Cohen
2017-07-05  3:50 ` Luke Dashjr
2017-07-05  4:00   ` shaolinfry
2017-07-05  4:10     ` Luke Dashjr
2017-07-05 19:44       ` Hampus Sjöberg
2017-07-06 17:20         ` Jorge Timón
2017-07-06 17:41           ` Eric Voskuil
2017-07-05  8:06   ` Gregory Maxwell
2017-07-05  8:54     ` Kekcoin [this message]
2017-07-06 20:43     ` Luke Dashjr
2017-07-07  5:52 ` shaolinfry
2017-07-07  9:51   ` Jorge Timón

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='akYjeiyeQP1gBjSOYOIbtnvgWVWjElJ065jNlZsDlbQ0TXoBlP9iJx2p9jOI4pKG5ltmPJsDPJ--rs8ruts6AiOgwZ-_dIfkT6b7hJwFb8A=@protonmail.com' \
    --to=kekcoin@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=greg@xiph.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