From: "Jorge Timón" <jtimon@jtimon•cc>
To: Cory Fields <lists@coryfields•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks
Date: Thu, 23 Jul 2015 20:12:33 +0200 [thread overview]
Message-ID: <CABm2gDquCeB7F5X6Drv_LcFcUYL6kL45swaMeZY31tQyXqknyA@mail.gmail.com> (raw)
In-Reply-To: <CAApLimjMPvXHM4McB+xBrho2hktz8Rr7QZyU-Dgbgd7sFdoyLw@mail.gmail.com>
On Thu, Jul 23, 2015 at 1:42 AM, 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.
For what is worth, here's yet another piece of code from the "doing
nothing" side:
https://github.com/bitcoin/bitcoin/pull/6382
It allows you to create a regtest-like testchain with a maximum block
size chosen at run time.
Rusty used a less generic testchain for testing 8 MB blocks:
http://rusty.ozlabs.org/?p=509
Unfortunately I don't know of anybody that has used my patch to test
any other size (maybe there's not that much interest in testing other
sizes after all?).
I'm totally in favor of preemptively adapting the code so that when a
new blocksize is to be deployed, adapting the code is not a problem.
Developers can agree on many changes in the code without users having
to agree on a concrete block size first.
I offer my help to do that. That's what I'm trying to do in #6382 and
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008961.html
but to my surprise that gets disregarded as "doing nothing" and as
"having a negative attitude", when not simply ignored.
next prev parent reply other threads:[~2015-07-23 18:12 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-22 22:40 Raystonn
2015-07-22 23:42 ` Cory Fields
2015-07-22 23:53 ` Eric Lombrozo
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 [this message]
-- 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=CABm2gDquCeB7F5X6Drv_LcFcUYL6kL45swaMeZY31tQyXqknyA@mail.gmail.com \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lists@coryfields$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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