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


[-- Attachment #1.1: Type: text/plain, Size: 4873 bytes --]

FWIW, I had worked on something similar a while back: https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf <https://github.com/CodeShark/bitcoin/blob/coinparams_new/altconf/bitcoin.conf>

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

> 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


[-- Attachment #1.2: Type: text/html, Size: 6785 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

  reply	other threads:[~2015-07-22 23:53 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 [this message]
2015-07-23  0:05     ` Cory Fields
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=068B7F93-A1DF-4F8D-84FC-B787C5429D6A@gmail.com \
    --to=elombrozo@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=lists@coryfields.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