public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon.cc>
To: Adam Back <adam@cypherspace.org>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin XT Fork
Date: Wed, 19 Aug 2015 19:28:38 +0200	[thread overview]
Message-ID: <CABm2gDrx3XEJX1WSAeyEpZ=cKb4-UB8tcFTKu8DMccZzfBsqYQ@mail.gmail.com> (raw)
In-Reply-To: <CALqxMTFkgGx0FxMiZ77inOZSs_+TQ88Wpj-q-c12COkO9tP4gQ@mail.gmail.com>

On Wed, Aug 19, 2015 at 6:53 PM, Adam Back via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> (and that in a hard fork it is not a miner vote really
> as in soft-forks).

I think calling it "miner vote" was the first mistake: miner's
shouldn't have a "voting power" the rest of the users lack.
I prefer to call it "miner upgrade confirmation" and in BIP99 the
recommendation is to use 95% for both uncontroversial softforks and
uncontroversial hardforks (the uncontroversial harforks also have a
minimum height before starting the miner confirmation/voting to give
users additional time to upgrade).
To me it's no different that the mechanism is used for uncontroversial
softforks or hardforks, the main question is that it is NOT a "miners'
democracy/oligopoly".
If you expect everyone (including all miners) to upgrade, I don't
think any less than 95% makes sense. On the other hand, 100% makes it
relatively cheap for an attacker to block uncontroversial consensus
changes.

For a Schism hardfork, bip99 doesn't recommend to use miner's
confirmation/vote at all. Miners could be against the change, for
example in an ASIC-reset Schism hardfork or in a "hardfork" (it cannot
be a softfork if miners oppose to it) to reduce the block size), but
that shouldn't stop the hardforkers if they think dividing the
currency in 2 is the best solution to whatever is the problem at hand
(which I don't think it's the case now).

Of course, BIP99 is still a draft and can still be changed. But I
would really like that we focused on "how to do hardforks in general"
first and only then focus on how to make a blocksize hardfork
concretely.


  parent reply	other threads:[~2015-08-19 17:28 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-19 16:53 [bitcoin-dev] Bitcoin XT Fork Adam Back
2015-08-19 17:22 ` Simon Liu
2015-08-19 18:13   ` Peter Todd
2015-08-19 23:37     ` Simon Liu
2015-08-19 17:28 ` Jorge Timón [this message]
2015-08-19 17:32 ` Btc Drak
2015-08-19 18:20   ` Peter Todd
2015-08-19 19:15     ` Btc Drak
2015-08-19 19:32       ` odinn
2015-08-19 19:48         ` Eric Lombrozo
2015-08-19 19:58           ` Jorge Timón
2015-08-19 20:04             ` Eric Lombrozo
2015-08-19 22:00               ` Jorge Timón
2015-08-19 23:07                 ` Eric Voskuil
2015-08-19 23:27                   ` Jorge Timón
2015-08-19 23:56                     ` Jorge Timón
2015-08-20  1:00                       ` GC
2015-08-20  1:17                         ` Jorge Timón
2015-08-20  0:08                     ` Eric Voskuil
2015-08-19 18:22   ` Jorge Timón
2015-08-19 19:12 ` Santino Napolitano
2015-08-19 19:28   ` Eric Lombrozo
2015-08-20  9:00 ` Mike Hearn
2015-08-20  9:13   ` Peter Todd
2015-08-21  3:01     ` odinn
  -- strict thread matches above, loose matches on Subject: below --
2015-08-19  8:25 Btc Drak
2015-08-17 20:24 Theo Chino
2015-08-18  4:56 ` Dave Scotese
2015-08-15 17:43 Satoshi Nakamoto
2015-08-15 19:08 ` Laszlo Hanyecz
2015-08-15 19:10 ` jl2012
2015-08-17 11:40 ` Oliver Egginger
2015-08-17 11:44   ` Jorge Timón
2015-08-17 11:51     ` Oliver Egginger
2015-08-17 16:32       ` Jorge Timón
2015-08-17 17:01         ` Oliver Egginger
2015-08-17 17:15           ` Jorge Timón
2015-08-17 17:30             ` Btc Drak
2015-08-17 17:18       ` Gregory Maxwell
2015-08-17 19:14         ` Peter Todd
2015-08-17 17:28   ` Jeff Garzik
2015-08-17 19:03   ` Warren Togami Jr.
2015-08-17 20:37     ` Oliver Egginger
2015-08-18  5:16       ` Gregory Maxwell
2015-08-18  9:15       ` Warren Togami Jr.
2015-08-18 11:52         ` Micha Bailey
2015-08-18 18:57         ` Oliver Egginger
2015-08-18 20:59           ` Anon Moto
2015-08-19  1:03             ` Sergio Demian Lerner
2015-08-17 19:02 ` Anon Moto
2015-08-17 19:40   ` Marcel Jamin
2015-08-17 19:16 ` Hector Chu
2015-08-17 19:28   ` Gregory Maxwell
2015-08-17 19:39     ` Jorge Timón
2015-08-19  2:54 ` odinn
2015-08-19  2:59   ` Angel Leon

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='CABm2gDrx3XEJX1WSAeyEpZ=cKb4-UB8tcFTKu8DMccZzfBsqYQ@mail.gmail.com' \
    --to=jtimon@jtimon.cc \
    --cc=adam@cypherspace.org \
    --cc=bitcoin-dev@lists.linuxfoundation.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