Date: Mon, 12 Oct 2015 00:02:51 -0700 (PDT)
MIME-Version: 1.0
Message-Id: <1444633370859.8a298e9c@Nodemailer>
In-Reply-To: <20151007150014.GA21849@navy>
References: <20151007150014.GA21849@navy>
From: digitsu@gmail.com
To: "Anthony Towns" <aj@erisian.com.au>
Content-Type: multipart/alternative;
	boundary="----Nodemailer-0.5.0-?=_1-1444633371062"
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Precedence: list

------Nodemailer-0.5.0-?=_1-1444633371062
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Thanks for that great breakdown Anthony. I think it helps a lot of us get a=
 better handle on the matter without getting too technical.=C2=A0


A couple of questions on some of the points you made I'd like to put out =
there:




First I think your unsaid assumption about the fragility of a soft fork =
showing incorrect confirmations is dependent on the percentage of hash =
power that didn't upgrade. =C2=A0If using your same numbers this was only =
5% of the hash power, the attack is effectively not effective (u less the =
attacker knew an exact merchant that was unfortunately on the minority of =
the network.=C2=A0




-- snip --


=C2=A0- non-upgraded bitcoin nodes: total breakage. there will be a push

=C2=A0 =C2=A0alert telling you to upgrade. anyone who doesn't will think =
they're

=C2=A0 =C2=A0tracking =22bitcoin=22 but will actually be tracking a new =
=22bitcoin-old=22

=C2=A0 =C2=A0altcoin. most non-upgraded miners will presumably realise =
they're

=C2=A0 =C2=A0wasting hashpower and stop doing this pretty quick; and =
remaining

=C2=A0 =C2=A0miners will only create blocks very slowly due to sudden =
reduced

=C2=A0 =C2=A0hashpower, without possibility of difficulty adjustment.=
=C2=A0

----




Is this true=3F I thought that un-upgraded nodes would just dump the new =
blocks from the upgraded miner majority as invalid. This how would they =
even know (besides the PSA) that they were on the wrong side=3F=C2=A0




----snip---

users who

=C2=A0 =C2=A0don't uprade will try to do transactions, but won't see them =
confirm

=C2=A0 =C2=A0for hours or days due to lack of hashpower.






----




But only for txns for users who are using the new OP code right=3F Regular =
transactions will get relayed by both upgraded and in-upgraded nodes and =
miners alike.=C2=A0








=E2=80=94
Regards,
------Nodemailer-0.5.0-?=_1-1444633371062
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html PUBLIC =22-//W3C//DTD HTML 4.0 Transitional//EN=22 =
=22http://www.w3.org/TR/REC-html40/loose.dtd=22>
<html><body><div id=3D=22mbx-wrapper=22>
<div id=3D=22mbx-content=22 class=3D=22content=22 onfocus=3D=22didBecomeFir=
stResponder()=22 contenteditable=3D=22true=22 onblur=3D=22didBlur()=22>Than=
ks for that great breakdown Anthony. I think it helps a lot of us get a =
better handle on the matter without getting too technical.=
&nbsp;<div><br></div>
<div>A couple of questions on some of the points you made I'd like to put =
out there:</div>
<div><br></div>
<div>First I think your unsaid assumption about the fragility of a soft =
fork showing incorrect confirmations is dependent on the percentage of hash=
 power that didn't upgrade. &nbsp;If using your same numbers this was only =
5% of the hash power, the attack is effectively not effective (u less the =
attacker knew an exact merchant that was unfortunately on the minority of =
the network.&nbsp;</div>
<div><br></div>
<div>-- snip --</div>
<div>
<div>&nbsp;- non-upgraded bitcoin nodes: total breakage. there will be a =
push</div>
<div>&nbsp; &nbsp;alert telling you to upgrade. anyone who doesn't will =
think they're</div>
<div>&nbsp; &nbsp;tracking =22bitcoin=22 but will actually be tracking a =
new =22bitcoin-old=22</div>
<div>&nbsp; &nbsp;altcoin. most non-upgraded miners will presumably realise=
 they're</div>
<div>&nbsp; &nbsp;wasting hashpower and stop doing this pretty quick; and =
remaining</div>
<div>&nbsp; &nbsp;miners will only create blocks very slowly due to sudden =
reduced</div>
<div>&nbsp; &nbsp;hashpower, without possibility of difficulty adjustment.=
&nbsp;</div>
<div>----</div>
<div><br></div>
<div>Is this true=3F I thought that un-upgraded nodes would just dump the =
new blocks from the upgraded miner majority as invalid. This how would they=
 even know (besides the PSA) that they were on the wrong =
side=3F&nbsp;</div>
<div><br></div>
<div>----snip---</div>
<div>users who</div>
<div>&nbsp; &nbsp;don't uprade will try to do transactions, but won't see =
them confirm</div>
<div>&nbsp; &nbsp;for hours or days due to lack of hashpower.</div>
</div>
<div><br></div>
<div>----</div>
<div><br></div>
<div>But only for txns for users who are using the new OP code right=3F =
Regular transactions will get relayed by both upgraded and in-upgraded =
nodes and miners alike.&nbsp;</div>
<div><br></div>
</div>
<div id=3D=22mbx-old-email=22 contenteditable=3D=22true=22><div =
class=3D=22mailbox=5Fsignature=22 style=3D=22display: block;=22>
<br>&mdash;
Regards,</div></div>
</div></body></html>

------Nodemailer-0.5.0-?=_1-1444633371062--