Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V213l-0004Yo-ND for bitcoin-development@lists.sourceforge.net; Wed, 24 Jul 2013 15:33:01 +0000 X-ACL-Warn: Received: from 216-155-145-223.cinfuserver.com ([216.155.145.223] helo=zooko.com) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1V213k-00065X-0t for bitcoin-development@lists.sourceforge.net; Wed, 24 Jul 2013 15:33:01 +0000 Received: by zooko.com (Postfix, from userid 1000) id 8217F1F30055; Wed, 24 Jul 2013 19:32:52 +0400 (MSK) Date: Wed, 24 Jul 2013 19:32:52 +0400 From: zooko To: Jeff Garzik Message-ID: <20130724153251.GE1009@zooko.com> References: <20130724023526.GD1009@zooko.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 TVD_RCVD_IP TVD_RCVD_IP 1.0 RDNS_DYNAMIC Delivered to internal network by host with dynamic-looking rDNS X-Headers-End: 1V213k-00065X-0t Cc: Bitcoin Dev , Greg Troxel Subject: Re: [Bitcoin-development] Linux packaging letter X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 15:33:01 -0000 On Wed, Jul 24, 2013 at 09:52:33AM -0400, Jeff Garzik wrote: > > I'm working on a more digestable alternative: > https://gist.github.com/jgarzik/6065679 Hi Jeff! Thanks for working on it. Even if that letter (https://gist.github.com/jgarzik/6065679) doesn't supplant https://docs.google.com/a/leastauthority.com/document/d/1naenR6N6fMWSpHM0f4jpQhYBEkCEQDbLBs8AXC19Y-o/edit#heading=h.i7tz3gqh65mi as a message-to-packagers, it looks like it will still turn out to be a useful text. My first question about it is this part: """ Make a mistake, lose $1 billion The consequences of bitcoin consensus failure are very high, comparable to avionics or medical device software. As of this writing, over $1 billion of value depends on bitcoin software being able to reliably achieve consensus over the worldwide Internet. This is the digital equivalent of Fort Knox: consensus must be achieved, or bitcoin has no value. """ This makes it sound like if, for example, Debian were to link bitcoind to the system leveldb, and then upgrade the system leveldb to fix a bug that affects bitcoind, that this would spell the end of Bitcoin. I hope that's not true! I'd like to try to be more specific about two things: 1. What is the behavior that a dependency or a patch could cause that would be problematic? I liked what Luke-Jr said earlier in this thread -- that in some cases a bitcoin node (i.e. a bitcoind process) needs certain bugs or limitations in order to maintain consensus with other bitcoin nodes. Maybe you could use a statement like that, without attempting to explain in *what* cases that applies. 2. What is the consequence if this goes wrong? This is something I don't understand as well. I think the answer is: 2.a. All bitcoin nodes which encounter one of these cases and are differently-buggy than the upstream bitcoind form their own consensus, causing a blockchain fork. 2.b. There is a risk of double-spending attacks. 2.c. The process for healing a blockchain fork is not very smooth or well-understood. Regards, Zooko