From: Ross Nicoll <jrn@jrn.me.uk>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Date: Thu, 18 Jun 2015 20:31:55 +0100 [thread overview]
Message-ID: <55831CAB.2080303@jrn.me.uk> (raw)
In-Reply-To: <CABm2gDoa7KxsgvREo3yiNjfd6AeayqAqkjMe2rvX8yyxR_ddcA@mail.gmail.com>
I've got a few thoughts on this, but they don't really attach well to a
single message, so starting a fresh message in the same thread. I'm
going to try being brief.
There's a lot of talk about not forking. Sorry, but they're going to
happen, planned and unplanned. Even if no intentional forks occur from
here on, I hope it's obvious that there will be further accidental forks
(at least unless and until someone prepares a formal proof of a Bitcoin
wallet). We need to be more comfortable with that, and plan ahead.
Education is key here, a lot of people don't understand what a fork is,
how it will affect them, how to recognise a fork or how to recover. I'll
dig out what materials I've written already and try making them more
widely available, as a start.
On whether code forks are a solution to disagreements - I'm not quite
sure what people expect will happen where a group believes there is an
existential threat to Bitcoin and they cannot get Bitcoin Core updated.
I may disagree with Mike & Gavin on timescale, but I do believe there's
a likelihood inaction will kill Bitcoin, and in that context I see the
rational choice as taking the perceived smaller risk of a fork killing
Bitcoin. BIP100 appears to be making progress, however, right now I
think the best option is pursuing it towards something that can be
agreed on by all. I would also happily go with an 8MB block size even if
just to buy us (IMHO a lot) more time.
Lastly, there seems to be a number of people who believe inaction
through apathy is fine. I respect those who form considered opinions and
tell me why they believe 1MB is fine, but I do ask that people either
put the effort in to help make decisions, or delegate to someone else.
Decentralised does not mean there's no decision making, it means we're
all decision makers, and frankly I think there's effectively negligence
in that capacity right now. I'd also point out this ongoing discussion
is a huge time sink to a number of people who could be making much more
useful contributions, and that again going in circles endlessly
discussing in the name of decentralisation isn't positive.
I have failed at being brief, apologies.
Ross
next prev parent reply other threads:[~2015-06-18 19:51 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 8:54 [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers odinn
2015-06-18 10:00 ` Mike Hearn
2015-06-18 11:14 ` Wladimir J. van der Laan
2015-06-18 11:47 ` Wladimir J. van der Laan
2015-06-18 13:36 ` Mike Hearn
2015-06-18 15:58 ` Gregory Maxwell
2015-06-18 12:29 ` Pieter Wuille
2015-06-18 12:50 ` Wladimir J. van der Laan
2015-06-18 12:56 ` Benjamin
2015-06-18 13:49 ` Mike Hearn
2015-06-18 14:05 ` Wladimir J. van der Laan
2015-06-18 14:16 ` Mike Hearn
2015-06-18 14:53 ` Milly Bitcoin
2015-06-18 14:56 ` Jeff Garzik
2015-06-18 15:13 ` Milly Bitcoin
2015-06-18 14:53 ` Jeff Garzik
2015-06-18 16:07 ` justusranvier
2015-06-18 16:28 ` Jeff Garzik
2015-06-18 17:04 ` justusranvier
2015-06-18 17:42 ` Alex Morcos
2015-06-18 18:01 ` Milly Bitcoin
2015-06-18 18:23 ` Gavin Andresen
2015-06-18 18:44 ` Alex Morcos
2015-06-18 18:49 ` Jorge Timón
2015-06-18 19:31 ` Ross Nicoll [this message]
2015-06-18 21:42 ` Matt Whitlock
2015-06-18 21:49 ` Mark Friedenbach
2015-06-18 21:58 ` Jeff Garzik
2015-06-18 22:33 ` Mark Friedenbach
2015-06-18 22:52 ` Jeff Garzik
2015-06-18 23:25 ` odinn
2015-06-18 23:16 ` Ross Nicoll
2015-06-19 0:57 ` Chris Pacia
2015-06-19 5:59 ` Eric Lombrozo
2015-06-19 9:37 ` Mike Hearn
2015-06-19 9:53 ` Benjamin
2015-06-19 10:08 ` GC
2015-06-19 10:19 ` Mike Hearn
2015-06-19 10:52 ` Eric Lombrozo
2015-06-19 11:31 ` Jorge Timón
2015-06-19 12:26 ` GC
2015-06-19 11:48 ` Brooks Boyd
2015-06-21 14:45 ` Owen Gunden
2015-06-18 21:55 ` Ross Nicoll
2015-06-18 19:24 ` Matt Corallo
2015-06-18 19:32 ` Gregory Maxwell
2015-06-18 12:38 ` Milly Bitcoin
2015-06-18 13:31 ` Mike Hearn
2015-06-18 13:50 ` Pieter Wuille
2015-06-18 15:03 ` Mark Friedenbach
2015-06-18 15:30 ` Milly Bitcoin
2015-06-18 15:46 ` Wladimir J. van der Laan
2015-06-18 16:05 ` Mike Hearn
2015-06-18 16:20 ` Wladimir J. van der Laan
2015-06-18 22:49 ` odinn
2015-06-18 16:11 ` Milly Bitcoin
2015-06-18 11:41 ` Lawrence Nahum
2015-06-18 14:33 ` Bryan Bishop
2015-06-18 18:09 ` Melvin Carvalho
2015-06-18 22:10 ` odinn
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=55831CAB.2080303@jrn.me.uk \
--to=jrn@jrn.me.uk \
--cc=bitcoin-development@lists.sourceforge.net \
/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