From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BA785323 for ; Sat, 27 Jun 2015 02:14:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.help.org (mail.help.org [70.90.2.18]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D45F9A8 for ; Sat, 27 Jun 2015 02:14:57 +0000 (UTC) Received: from [10.1.10.25] (B [10.1.10.25]) by mail.help.org with ESMTPA ; Fri, 26 Jun 2015 22:14:52 -0400 References: <20150623192838.GG30235@muck> <20150623204646.GA18677@muck> <20150626192528.GC10387@muck> <558DCF2F.5080305@bitcartel.com> To: bitcoin-dev@lists.linuxfoundation.org From: Milly Bitcoin Message-ID: <558E0717.40502@bitcoins.info> Date: Fri, 26 Jun 2015 22:14:47 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <558DCF2F.5080305@bitcartel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2015 02:14:58 -0000 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 >