Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E02A31072 for ; Wed, 30 Dec 2015 17:58:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 52B95181 for ; Wed, 30 Dec 2015 17:58:47 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id yy13so48772191pab.3 for ; Wed, 30 Dec 2015 09:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-transfer-encoding:content-type:from:mime-version:subject :message-id:date:to:cc; bh=EuA3CYuJ4tJx45UislkGGf12LaCpZIk3JYDfYNQbrYs=; b=SR6B99npNXXlpc5j298xzrjkZxoDIHv+wk7nO3q7gVsaAlY02U/qD4c2JrwFemskWp LGFfhXwPARrdUx5mfskqO+w366dkOR30uCwXg5tWoBJnhaYMw8uGrEb3WPkjdYRwq4YH XiM9lHwd/I1lDAwSsHnPo39V/6r4zetbJFu8jYUFYVj69YtLdW6MyhtNefcvcAJmx/3V sDi6OVUU/+qviO5JASS+cr53oHlyzGb4t0reuba0dp3R8C46C3Pr/kEjuHoZHhCKDoGg r08D3vyuJIKANzMLvbInnVGn3Pk+YNeJQEhpAOhicHs2GzE2GeGJgWgu2dNF7mP0I7aG dnAg== X-Received: by 10.66.161.70 with SMTP id xq6mr94475616pab.73.1451498326953; Wed, 30 Dec 2015 09:58:46 -0800 (PST) Received: from [10.70.214.138] (124x33x172x65.ap124.ftth.ucom.ne.jp. [124.33.172.65]) by smtp.gmail.com with ESMTPSA id n26sm85295779pfb.39.2015.12.30.09.58.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Dec 2015 09:58:46 -0800 (PST) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-32521476-D42B-4BB1-A743-7FFF5E53FC5E From: David Chan Mime-Version: 1.0 (1.0) Message-Id: <0DD6A08C-897A-49D6-BDDE-00C6B94DB281@gmail.com> Date: Thu, 31 Dec 2015 02:58:44 +0900 To: joe2015@openmailbox.org X-Mailer: iPhone Mail (13C75) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 30 Dec 2015 18:01:05 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: [bitcoin-dev] Generalized soft forks 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: Wed, 30 Dec 2015 17:58:48 -0000 --Apple-Mail-32521476-D42B-4BB1-A743-7FFF5E53FC5E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Please forgive the perhaps pedantic question but in the referred document http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.= html It talks about how a soft fork with >50% support will doom the other fork to= being orphaned eventually but that hard forks could persist forever. I fai= l to see why the same logic that one side having the majority will eventuall= y win wouldn't also apply to hard forks. =20 Additionally it seems to me that a notable difference between a generalized s= oft fork as described and a hard fork majority is in the process by which th= ey force the other fork to be orphaned. In a hard fork an unupgraded node wo= uld know you were in a forking situation due to your node getting a lot of b= locks from the other fork and having to reject them (because they are invali= d) whereas in a generalized soft fork you wouldn't know there was a fork goi= ng on so there would be less of an impetus to upgrade. Of course the downsi= de of the hard fork is that the losing side would potentially lose money in t= he orphaned chain, but presumably this discussion of generalized soft forks i= s with regards to non-mining nodes so it shouldn't come into consideration.=20= In fact if an non-upgraded miner were to start mining on top of that block w= hich they cannot actually fully validate essentially this condones mining wi= thout verification (and trusting that others which have upgraded nodes to ha= ve validated the txns for you) as this situation can continue for a prolonge= d period of time does this not hurt network security ? >> On 2015/12/31, at 1:27, joe2015--- via bitcoin-dev wrote: >>=20 >> On 2015-12-30 18:33, Marco Falke wrote: >> This is an interesting approach but I don't see how this is a soft >> fork. (Just because something is not a hard fork, doesn't make it a >> soft fork by definition) >> Softforks don't require any nodes to upgrade. [1] >> Nonetheless, as I understand your approach, it requires nodes to >> upgrade. Otherwise they are missing all transactions but the coinbase >> transactions. Thus, they cannot update their utxoset and are easily >> susceptible to double spends... >> Am I missing something obvious? >> -- Marco >> [1] https://en.bitcoin.it/wiki/Softfork#Implications >=20 > It just depends how you define "softfork". In my original write-up I call= ed it a "generalized" softfork, Peter suggested a "firm" fork, and there are= some suggestions for other names. Ultimately what you call it is not very i= mportant. >=20 > --joe. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-32521476-D42B-4BB1-A743-7FFF5E53FC5E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Please f= orgive the perhaps pedantic question but in the referred document
It talks about how a soft fork wi= th >50% support will doom the other fork to being orphaned eventually but= that hard forks could persist forever.  I fail to see why the same log= ic that one side having the majority will eventually win wouldn't also apply= to hard forks.  

Additionally it seems to me t= hat a notable difference between a generalized soft fork as described and a h= ard fork majority is in the process by which they force the other fork to be= orphaned. In a hard fork an unupgraded node would know you were in a forkin= g situation due to your node getting a lot of blocks from the other fork and= having to reject them (because they are invalid) whereas in a generalized s= oft fork you wouldn't know there was a fork going on so there would be less o= f an impetus to upgrade.  Of course the downside of the hard fork is th= at the losing side would potentially lose money in the orphaned chain, but p= resumably this discussion of generalized soft forks is with regards to non-m= ining nodes so it shouldn't come into consideration. 

In fact if an non-upgraded miner were to start mining on top of that= block which they cannot actually fully validate essentially this condones m= ining without verification (and trusting that others which have upgraded nod= es to have validated the txns for you) as this situation can continue for a p= rolonged period of time does this not hurt network security ?

=


On 2015/12/3= 1, at 1:27, joe2015--- via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:=

On 2015-12-30 1= 8:33, Marco Falke wrote:
This is an interesting approach b= ut I don't see how this is a soft
fork. (Just because some= thing is not a hard fork, doesn't make it a
soft fork by d= efinition)
Softforks don't require any nodes to upgrade. [= 1]
Nonetheless, as I understand your approach, it requires= nodes to
upgrade. Otherwise they are missing all transact= ions but the coinbase
transactions. Thus, they cannot updat= e their utxoset and are easily
susceptible to double spend= s...
Am I missing something obvious?
-- M= arco
[1] https://en.bitcoin.it/wiki/Softfork#Implications
<= /blockquote>

It just depends how you define "softfor= k".  In my original write-up I called it a "generalized" softfork, Pete= r suggested a "firm" fork, and there are some suggestions for other names. &= nbsp;Ultimately what you call it is not very important.

--joe.
_= ______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
=
https://lists.linuxfoundation.org/mailman/lis= tinfo/bitcoin-dev
= --Apple-Mail-32521476-D42B-4BB1-A743-7FFF5E53FC5E--