From: Milly Bitcoin <milly@bitcoins.info>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Date: Fri, 26 Jun 2015 22:14:47 -0400 [thread overview]
Message-ID: <558E0717.40502@bitcoins.info> (raw)
In-Reply-To: <558DCF2F.5080305@bitcartel.com>
It is actually not odd at all that a formal process is dismissed out of
hand. It is all about protecting turf and holding on to power. If
there is a well defined process then that takes the power out of the
hands of the people who have been running the show and making up the
rules. In some cases developers see Bitcoin as their "baby" and they
think they must control it in order to protect it but in doing so they
can become an "overprotective parent." Another problem is that some
people in Bitcoin have disdain for the people they need such as
financial, economic, security, and legal experts. Some think they are
smarter than those people because they discovered Bitcoin first and they
think their knowledge of Bitcoin means they are also superior in all
these other areas. I have seen some discussions of developers who have
met with people from the financial sector and they come out of the
meeting with the attitude that all the experts are stupid and that
Bitcoiners have everything figured out. One developer tried to tell me
that you can't do systems engineering in Bitcoin because it involves
security rather than safety (of course that issue has been well vetted
and NIST has a whole series of documents to address that very issue
http://csrc.nist.gov/publications/PubsSPs.html).
Russ
On 6/26/2015 6:16 PM, Simon Liu wrote:
> If Bitcoin is a $3bn project where stakeholder interests are to be
> safeguarded, or if Bitcoin is to be compared to a civil engineering
> project where life and death is at stake, it seems only logical that a
> well-defined and well-documented process be introduced to properly
> evaluate proposed changes. Although too late for the block size debate,
> it seems odd that discussion of such a process is often dismissed out of
> hand.
>
> To maintain the current approach of supermajority consensus, based
> around ingrained wisdom, personal preference and unwritten rules would
> suggest that Bitcoin is still an experiment, in which case perhaps any
> decision regarding the block size should be based upon technical merit
> alone rather than economic interest.
>
> --Simon
>
>> You're the one proposing a change here; we're evaluating the safety of
> that change.
>
>> In civil engineering we have enough experience with disasters to know
>> that you can't give into political pressure to do potentially dangerous
>> things until the consequences are well understood; hopefully we'll learn
>> that in the consensus cryptography space before a big disaster rather
>> than after.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
next prev parent reply other threads:[~2015-06-27 2:14 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-22 18:18 [bitcoin-dev] Draft BIP : fixed-schedule block size increase Gavin Andresen
2015-06-22 18:33 ` Tier Nolan
2015-06-22 18:46 ` Gavin Andresen
2015-06-22 19:10 ` Martin Schwarz
2015-06-22 19:28 ` Tier Nolan
2015-06-22 19:54 ` Gavin Andresen
2015-06-22 20:12 ` Peter Todd
2015-06-22 19:23 ` Peter Todd
2015-06-23 7:35 ` Ross Nicoll
2015-08-17 15:58 ` Jorge Timón
2015-06-23 19:16 ` Peter Todd
2015-06-22 20:27 ` Kalle Rosenbaum
2015-06-22 20:46 ` Gavin Andresen
2015-06-22 20:51 ` Gavin Andresen
2015-06-22 21:52 ` Mark Friedenbach
2015-06-23 19:28 ` Peter Todd
2015-06-23 20:12 ` Gavin Andresen
2015-06-23 20:26 ` Pieter Wuille
2015-06-23 20:50 ` Peter Todd
2015-06-24 6:14 ` grarpamp
2015-06-23 20:46 ` Peter Todd
2015-06-23 21:24 ` Gavin Andresen
2015-06-26 19:08 ` Peter Todd
2015-06-26 22:01 ` Ivan Brightly
2015-06-26 19:25 ` Peter Todd
2015-06-26 22:16 ` Simon Liu
2015-06-27 2:14 ` Milly Bitcoin [this message]
2015-06-23 20:55 ` Roy Badami
2015-06-24 1:43 ` odinn
2015-06-24 3:05 ` William Madden
2015-06-24 3:49 ` Jeff Garzik
2015-06-24 13:06 ` Will
2015-06-24 13:44 ` Gavin Andresen
2015-06-25 0:32 ` Pindar Wong
2015-06-25 13:50 ` Gareth Williams
2015-06-25 14:07 ` Adam Back
2015-06-26 13:47 ` Tier Nolan
2015-06-26 15:13 ` Will
2015-06-26 17:39 ` Gavin Andresen
2015-06-26 19:07 ` Will
2015-07-01 22:49 ` odinn
2015-08-17 13:15 ` Tier Nolan
2015-08-17 13:18 ` Clément Elbaz
2015-08-19 3:45 ` odinn
2015-08-17 16:11 ` Jorge Timón
2015-06-26 21:07 ` Carsten Otto
2015-06-22 19:32 Jean-Paul Kogelman
2015-06-22 20:43 ` Tier Nolan
2015-06-22 20:54 ` Peter Todd
2015-06-22 21:04 ` Stephen Morse
2015-06-22 21:32 ` Ross Nicoll
2015-08-17 15:54 ` Jorge Timón
2015-06-22 21:21 ` Gavin Andresen
2015-06-22 21:39 ` Patrick Strateman
2015-06-22 21:48 ` Tier Nolan
2015-06-23 7:59 Ross Nicoll
2015-06-24 4:31 Raystonn
2015-06-24 17:05 ` Mark Friedenbach
2015-06-24 17:24 ` Roy Badami
2015-06-24 17:23 Raystonn
2015-06-24 17:24 ` Allen Piscitello
2015-06-24 17:28 ` Roy Badami
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=558E0717.40502@bitcoins.info \
--to=milly@bitcoins.info \
--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