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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Generalized soft forks
Precedence: list


--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--