path: root/2e/a4467a766abec162ed5c803810f5f8a06f5f8c

Return-Path: <digitsu@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E02A31072
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 30 Dec 2015 17:58:47 +0000 (UTC)
Received: by mail-pa0-f52.google.com with SMTP id yy13so48772191pab.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <digitsu@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@lists.lin=
uxfoundation.org> 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

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><span></span></div><div><span>Please f=
orgive the perhaps pedantic question but in the referred document</span></di=
v><div><a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
5-December/012073.html">http://lists.linuxfoundation.org/pipermail/bitcoin-d=
ev/2015-December/012073.html</a></div><div>It talks about how a soft fork wi=
th &gt;50% support will doom the other fork to being orphaned eventually but=
 that hard forks could persist forever. &nbsp;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. &nbsp;</div><div><br></div><div>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. &nbsp;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.&nbsp;</div><div><br></d=
iv><div>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 ?</div><div><br>=
</div><div><br><span></span><br><blockquote type=3D"cite"><span>On 2015/12/3=
1, at 1:27, joe2015--- via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:=
</span><br></blockquote><blockquote type=3D"cite"><span></span><br></blockqu=
ote><blockquote type=3D"cite"><blockquote type=3D"cite"><span>On 2015-12-30 1=
8:33, Marco Falke wrote:</span><br></blockquote></blockquote><blockquote typ=
e=3D"cite"><blockquote type=3D"cite"><span>This is an interesting approach b=
ut I don't see how this is a soft</span><br></blockquote></blockquote><block=
quote type=3D"cite"><blockquote type=3D"cite"><span>fork. (Just because some=
thing is not a hard fork, doesn't make it a</span><br></blockquote></blockqu=
ote><blockquote type=3D"cite"><blockquote type=3D"cite"><span>soft fork by d=
efinition)</span><br></blockquote></blockquote><blockquote type=3D"cite"><bl=
ockquote type=3D"cite"><span>Softforks don't require any nodes to upgrade. [=
1]</span><br></blockquote></blockquote><blockquote type=3D"cite"><blockquote=
 type=3D"cite"><span>Nonetheless, as I understand your approach, it requires=
 nodes to</span><br></blockquote></blockquote><blockquote type=3D"cite"><blo=
ckquote type=3D"cite"><span>upgrade. Otherwise they are missing all transact=
ions but the coinbase</span><br></blockquote></blockquote><blockquote type=3D=
"cite"><blockquote type=3D"cite"><span>transactions. Thus, they cannot updat=
e their utxoset and are easily</span><br></blockquote></blockquote><blockquo=
te type=3D"cite"><blockquote type=3D"cite"><span>susceptible to double spend=
s...</span><br></blockquote></blockquote><blockquote type=3D"cite"><blockquo=
te type=3D"cite"><span>Am I missing something obvious?</span><br></blockquot=
e></blockquote><blockquote type=3D"cite"><blockquote type=3D"cite"><span>-- M=
arco</span><br></blockquote></blockquote><blockquote type=3D"cite"><blockquo=
te type=3D"cite"><span>[1] <a href=3D"https://en.bitcoin.it/wiki/Softfork#Im=
plications">https://en.bitcoin.it/wiki/Softfork#Implications</a></span><br><=
/blockquote></blockquote><blockquote type=3D"cite"><span></span><br></blockq=
uote><blockquote type=3D"cite"><span>It just depends how you define "softfor=
k". &nbsp;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.</span><br></blockquo=
te><blockquote type=3D"cite"><span></span><br></blockquote><blockquote type=3D=
"cite"><span>--joe.</span><br></blockquote><blockquote type=3D"cite"><span>_=
______________________________________________</span><br></blockquote><block=
quote type=3D"cite"><span>bitcoin-dev mailing list</span><br></blockquote><b=
lockquote type=3D"cite"><span><a href=3D"mailto:bitcoin-dev@lists.linuxfound=
ation.org">bitcoin-dev@lists.linuxfoundation.org</a></span><br></blockquote>=
<blockquote type=3D"cite"><span><a href=3D"https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/lis=
tinfo/bitcoin-dev</a></span><br></blockquote></div></body></html>=

--Apple-Mail-32521476-D42B-4BB1-A743-7FFF5E53FC5E--