public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Cory Fields <lists@coryfields.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Date: Wed, 22 Jul 2015 20:05:53 -0400	[thread overview]
Message-ID: <CAApLimjiF6zH8GAbTajMTW6p8GtXCGRa5GcV+N2z1soY5fQy+A@mail.gmail.com> (raw)
In-Reply-To: <068B7F93-A1DF-4F8D-84FC-B787C5429D6A@gmail.com>

On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:
> FWIW, I had worked on something similar a while back:
> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>
> I like the idea in principle…but we should require a new genesis block,
> different magic bytes, and a different network port at the very least. :)
>

Not sure if serious, so I'll assume you are :)

Why? The idea in this case would be to allow the user to decide
between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
runtime rather than the likely alternative of "./bitcoind" vs
"./bitcoin-fork".

Chain params may be identical other than the value of some future
event (miner vote for example), in which case the configs would run
identically until that point.

If your concern is about nodes with different configs communicating
with eachother, I'd like to reiterate: the idea really is no different
than suggesting that someone fork the codebase and implement their own
changes, it just cuts out most of the work required.

Cory

> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.
>
> I realize that it'd be opening Pandora's Box, and likely met with very
> loud and reasonable arguments about the obvious terrible implications,
> but it's at least an alternative to the current status quo of Core's
> conflation with the consensus rules. The idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.
>
> With that in place, consensus changes would be more about lobbying and
> coalitions, and less about pull requests.
>
> Cory
>
> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> If the developers fail to reflect user consensus, the network will let us
> know.
>
>
> This is true with the caveat that there must be more than one option present
> for the network to show it's preference.  If developers discourage anything
> that forks from the rules enforced by Bitcoin Core, they harm the network's
> ability to inform us of a failure to reflect user consensus.
>
> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I wouldn't go quite that far.  The reality is somewhere in the middle, as
> Bryan Cheng noted in this thread:
>
> Quoting BC,
>
> Upgrading to a version of Bitcoin Core that is incompatible with your
> ideals is in no way a forced choice, as you have stated in your email;
> forks, alternative clients, or staying on an older version are all valid
> choices. If the majority of the network chooses not to endorse a specific
> change, then the majority of the network will continue to operate just fine
> without it, and properly structured consensus rules will pull the minority
> along as well.
>
>
> The developers propose a new version, by publishing a new release.  The
> individual network nodes choose to accept or reject that.
>
> So I respectfully disagree with "core devs don't control the network" and
> "core devs control the network" both.
>
> There are checks-and-balances that make the system work.  Consensus is most
> strongly measured by user actions after software release.  If the developers
> fail to reflect user consensus, the network will let us know.
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi Pieter,
>
> I think a core area of disagreement is this:
>
> Bitcoin Core is not running the Bitcoin economy, and its developers have no
> authority to set its rules.
>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make a
> release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


  reply	other threads:[~2015-07-23  0:05 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-22 22:40 [bitcoin-dev] Bitcoin Core and hard forks Raystonn
2015-07-22 23:42 ` Cory Fields
2015-07-22 23:53   ` Eric Lombrozo
2015-07-23  0:05     ` Cory Fields [this message]
2015-07-23  0:13       ` Eric Lombrozo
2015-07-23  0:34         ` Cory Fields
2015-07-23  0:43           ` Eric Lombrozo
2015-07-23  7:24             ` Ross Nicoll
2015-07-23  0:49         ` Eric Voskuil
2015-07-23 18:12   ` Jorge Timón
  -- strict thread matches above, loose matches on Subject: below --
2015-07-27 17:05 Alice Larson
2015-07-27 17:22 ` Eric Voskuil
2015-07-28  4:55   ` Wladimir J. van der Laan
     [not found] <BA7ACCE1-81B2-4AC1-B6DD-7A856FD27D52@gmail.com>
2015-07-23  8:24 ` Gareth Williams
     [not found] <CAPg+sBgs-ouEMu=LOVCmOyCGwfM1Ygxooz0shyvAuHDGGZYfJw@mail.gmail.com>
2015-07-22 16:52 ` Pieter Wuille
2015-07-22 17:18   ` Ross Nicoll
2015-07-22 17:32   ` Milly Bitcoin
2015-07-22 18:45     ` Bryan Cheng
2015-07-22 17:33   ` Jeff Garzik
2015-07-22 18:01     ` Jeff Garzik
2015-07-22 18:03     ` Alex Morcos
2015-07-22 18:24       ` Jeff Garzik
2015-07-23 12:17         ` Jorge Timón
2015-07-23 16:17           ` Tom Harding
2015-07-23 16:28             ` Gavin Andresen
2015-07-23 16:50               ` cipher anthem
2015-07-23 17:14                 ` Robert Learney
2015-07-23 18:21                   ` Eric Lombrozo
2015-07-23 18:47                   ` Jorge Timón
2015-07-23 17:43               ` Eric Lombrozo
2015-07-23 18:10                 ` Jameson Lopp
2015-07-23 19:14                   ` Eric Lombrozo
2015-07-23 19:35                     ` Gavin Andresen
2015-07-23 19:39                       ` Eric Lombrozo
2015-07-23 19:51                       ` Eric Lombrozo
2015-07-23 19:52                     ` Jameson Lopp
2015-07-23 20:26                       ` Jorge Timón
2015-07-23 20:52                         ` Eric Lombrozo
2015-07-23 23:42                           ` Benedict Chan
     [not found]                             ` <42BF7FEB-320F-43BE-B3D9-1D76CB8B9975@gmai>
2015-07-23 23:57                             ` Eric Lombrozo
2015-07-24  0:04                               ` Eric Lombrozo
2015-07-24  0:20                                 ` Simon Liu
2015-07-24  0:22                                 ` Jean-Paul Kogelman
2015-07-24  0:32                                   ` Eric Lombrozo
2015-07-24  0:38                                     ` Eric Lombrozo
2015-07-24  0:45                                     ` Jean-Paul Kogelman
2015-07-24  0:49                                       ` Jean-Paul Kogelman
2015-07-24  0:53                                         ` Peter Todd
2015-07-24  1:03                                           ` Jean-Paul Kogelman
2015-07-24  1:08                                             ` Eric Lombrozo
2015-07-24  1:25                                               ` Jean-Paul Kogelman
2015-07-24  1:28                                                 ` Eric Lombrozo
2015-07-24  1:37                                                   ` Eric Lombrozo
2015-07-24  1:42                                                   ` Jean-Paul Kogelman
2015-07-24  1:55                                                     ` Eric Lombrozo
2015-07-24  0:56                                       ` Eric Lombrozo
2015-07-24  1:05                                         ` Jean-Paul Kogelman
2015-07-23 18:12               ` Slurms MacKenzie
2015-07-23 18:57                 ` Mike Hearn
2015-07-23 17:51             ` Jorge Timón
2015-07-24  6:30               ` Tom Harding
2015-07-24  9:24                 ` Jorge Timón
2015-07-24 22:50                   ` Tom Harding
2015-07-28 11:29                     ` Jorge Timón
2015-07-28 11:32                       ` Jorge Timón
2015-07-28 16:44                       ` Tom Harding
2015-07-28 17:33                         ` Jorge Timón
2015-07-22 19:17     ` Eric Lombrozo
2015-07-22 21:43   ` Mike Hearn
2015-07-22 21:56     ` Eric Lombrozo
2015-07-22 22:01       ` Mike Hearn
2015-07-22 22:09         ` Eric Lombrozo
2015-07-23  1:53         ` Eric Lombrozo
2015-07-22 22:30     ` Jeff Garzik
2015-07-23  0:27   ` Tom Harding
2015-07-23  0:37     ` Eric Lombrozo
2015-07-23  4:40   ` Edmund Edgar
2015-07-27 12:08   ` Peter Todd
2015-07-27 12:44     ` Milly Bitcoin

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=CAApLimjiF6zH8GAbTajMTW6p8GtXCGRa5GcV+N2z1soY5fQy+A@mail.gmail.com \
    --to=lists@coryfields.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=elombrozo@gmail.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