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 BE7DD1550 for ; Mon, 5 Oct 2015 20:54:40 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 22ABF1DF for ; Mon, 5 Oct 2015 20:54:40 +0000 (UTC) Received: by wiclk2 with SMTP id lk2so132120626wic.1 for ; Mon, 05 Oct 2015 13:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=ujn7b5Q0EPlAxU1WRBKdgJFrtNrFp8XQua0o6qlVZIs=; b=zD+IKY6hb3pOo287vzjaiy0vuyjPtMAsuTASjq3mYFOpLb3TePBokFaFGjbWX2nujt s176SpO2YdlOcByGRx3cUAScWehbNGXe7DrKj4hpUblE6ZjVF8agZRD3zR05wN0oXGs+ pmY8/4q93NyNkk+7yPW8WNZJDL4RT6avExZj6Q345yJLdMMaBM5e54s5JBufwmUyb7lN LGKrDXXZpjKO43gegqZ5sjYZdSgxVFd6XXqkNHRLutqoRoinqVR1gdc5rD5sHJgX4NVO 6Ss0IRIkQR7Dzvf2csOzjwPdF1Uebhkn9pGLVbpgfuSgpMipEJSwhl2lyTqzwetUXob9 C7lw== MIME-Version: 1.0 X-Received: by 10.194.76.67 with SMTP id i3mr36973646wjw.5.1444078478805; Mon, 05 Oct 2015 13:54:38 -0700 (PDT) Sender: dscotese@gmail.com Received: by 10.27.211.132 with HTTP; Mon, 5 Oct 2015 13:54:38 -0700 (PDT) In-Reply-To: <2081461.sDX5ARzIdv@garp> References: <1489086.kGfJeeyi4a@garp> <2081461.sDX5ARzIdv@garp> Date: Mon, 5 Oct 2015 13:54:38 -0700 X-Google-Sender-Auth: hekyjattYvSvxyK3rP5iYKHw4UQ Message-ID: From: Dave Scotese To: Bitcoin Dev Content-Type: multipart/alternative; boundary=047d7bdc87aac1d6b4052161b8d1 X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_IMAGE_ONLY_24, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, T_REMOTE_IMAGE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] This thread is not about the soft/hard fork technical debate 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: Mon, 05 Oct 2015 20:54:40 -0000 --047d7bdc87aac1d6b4052161b8d1 Content-Type: text/plain; charset=UTF-8 I prefer the hard fork because the complexity introduced by soft forks scares me. At http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011309.html Gregory wrote: "Security requires a bit of vigilance, inherently." and [A non-upgraded miner will end up] "*> producing invalid blocks forever until** the owner shuts it down and upgrades. * This is the outcome guaranteed for absentee miners with a hard fork, but it is not guaranteed for a soft fork." It seems that the main benefit of a soft-fork is that it allows participants on the network to keep participating even if they aren't vigilant enough to notice and upgrade when that is safest. Are there other reasons that might entice me if that one by itself is not enough? Gregory provided two more: [Using soft-forks] "radically lowers (in most of our experience and opinion) the cost of deployment; again-- making them different. They prevent a industry wide flag day, and tight release synchronization which is harmful to decentralization promoting software diversity." I understand these benefits. The cost in complexity is still too high for me, and I think most of the pain in "cost of deployment", "industry-wide flag days," and "tight release synchronization," as well as the centralizing effect of those things can be minimized with waiting periods. The promotion of software diversity offered by soft-forks is pretty cool, but that gets close to messing with fungibility. --047d7bdc87aac1d6b4052161b8d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I prefer the hard fork because the complexity introduced b= y soft forks scares me.

At http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/0113= 09.html Gregory wrote: "Security requires a bit of vigilance, inhe= rently." and
[A non-upgraded miner will end up] "> prod= ucing invalid blocks forever until the owner shuts it down and upgra= des. This is the outcome guaranteed for absentee miners with a hard fork, but it is not guaranteed for a soft fork."

It seems that=20 the main benefit of a soft-fork is that it allows participants on the=20 network to keep participating even if they aren't vigilant enough to=20 notice and upgrade when that is safest.=C2=A0 Are there other reasons that= =20 might entice me if that one by itself is not enough?

Greg= ory provided two more: [Using soft-forks] "radically lowers (in most o= f our experience and
opinion) the cost of deployment; again-- making them different. They preven= t a industry wide flag day, and tight release synchronization=C2=A0 which is harmful to decentralization promoting software diversity."
I understand these benefits.=C2=A0 The cost in complexity i= s still too high for me, and I think most of the pain in "cost of depl= oyment", "industry-wide flag days," and "tight release = synchronization," as well as the centralizing effect of those things c= an be minimized with waiting periods.=C2=A0 The promotion of software diver= sity offered by soft-forks is pretty cool, but that gets close to messing w= ith fungibility.=C2=A0
--047d7bdc87aac1d6b4052161b8d1--