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

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

Thanks AJ,




That is a must more concise example, which I think makes it very clear all =
the variables at play.=C2=A0




I agree with its conclusion.=C2=A0




Though I'm wondering about its actual significance in ability to do harm as=
 with 5% hash power we would have to wait quite a long time before such a =
block was created and it would be unpredictable when exactly this would =
occur, and in order to actually execute such a double spend maliciously you=
 would have to 1) notice that such a block was mined and 2) be in a =
position to double spend a payment with a merchant for physical goods who =
you would know was using an SPV wallet at that exact time, correct=3F (By =
deliberately publishing a txn which would be blocked by the upgraded =
network)

Isn't that in itself unlikely enough to make this form of double spend =
unlikely to be exploitable=3F




Perhaps with malicious wallet software which always publishes =22bad=22 =
(will be mostly rejected) txn first and then retries with a normal one=3F




But I agree with you that if the risk is there why not avoid it if possible=
. =C2=A0



=E2=80=94
Regards,

On Tue, Oct 13, 2015 at 2:06 AM, Anthony Towns via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, Oct 12, 2015 at 12:02:51AM -0700, digitsu412 via bitcoin-dev =
wrote:
>> 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
> Actually, just to take this scenario more explicitly...
> Say you've got 5% of hashpower running on old software, along with,
> say, 1500 nodes; and meanwhile you've got 95% of hashpower running new
> software, along with 4000 nodes.
> There's still about 750 nodes running 0.9 or 0.8 of 5400 total according
> to bitnodes.21.co/nodes, so those numbers seems at least plausible to
> me for the first week or two after a soft-fork is activated.
> Eventually an old-rules block gets found by the 5% hashpower. The 4000
> new nodes and 95% of hashpower ignore it, of course. With 8 random
> connections, old nodes should have 92% chance of seeing an old node
> as a peer, so I think around ~1300 of them should still be a connected
> subgraph, and the old-rules block should get propogated amongst them
> (until two new-rules blocks come along and orphan it).
> An SPV client with 12 random connections here has 96% chance of having =
one
> of the ~1300 old nodes as a peer, and if so, will see the old-rules block=
,
> that will be orphaned, and may be at risk from double-spends as a result.=

> So I think even with just 5% hashpower and ~30% of nodes left running
> the old version, a =22damaging soft fork=22 still poses a fairly high =
risk to
> someone receiving payments via an SPV client, and trusting transactions
> with few confirmations.
> Cheers,
> aj
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
------Nodemailer-0.5.0-?=_1-1444694929051
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


<div>Thanks AJ,</div>
<div><br></div>
<div>That is a must more concise example, which I think makes it very clear=
 all the variables at play.=C2=A0</div>
<div><br></div>
<div>I agree with its conclusion.=C2=A0</div>
<div><br></div>
<div>Though I'm wondering about its actual significance in ability to do =
harm as with 5% hash power we would have to wait quite a long time before =
such a block was created and it would be unpredictable when exactly this =
would occur, and in order to actually execute such a double spend =
maliciously you would have to 1) notice that such a block was mined and 2) =
be in a position to double spend a payment with a merchant for physical =
goods who you would know was using an SPV wallet at that exact time, =
correct=3F (By deliberately publishing a txn which would be blocked by the =
upgraded network)</div>
<div>Isn't that in itself unlikely enough to make this form of double spend=
 unlikely to be exploitable=3F</div>
<div><br></div>
<div>Perhaps with malicious wallet software which always publishes =
=22bad=22 (will be mostly rejected) txn first and then retries with a =
normal one=3F</div>
<div><br></div>
<div>But I agree with you that if the risk is there why not avoid it if =
possible. =C2=A0</div>
<div class=3D=22mailbox=5Fsignature=22>
<br>=E2=80=94
Regards, </div>
<br><br><div class=3D=22gmail=5Fquote=22><p>On Tue, Oct 13, 2015 at 2:06 AM=
, Anthony Towns via bitcoin-dev <span dir=3D=22ltr=22>&lt;<a =
href=3D=22mailto:bitcoin-dev@lists.linuxfoundation.org=22 =
target=3D=22=5Fblank=22>bitcoin-dev@lists.linuxfoundation.=
org</a>&gt;</span> wrote:<br></p><blockquote class=3D=22gmail=5Fquote=22 =
style=3D=22margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
=22><p>On Mon, Oct 12, 2015 at 12:02:51AM -0700, digitsu412 via bitcoin-dev=
 wrote:
<br>&gt; First I think your unsaid assumption about the fragility of a =
soft
<br>&gt; fork showing incorrect confirmations is dependent on the =
percentage
<br>&gt; of hash power that didn't upgrade. =C2=A0If using your same =
numbers this
<br>&gt; was only 5% of the hash power, the attack is effectively not =
effective
<br>&gt; (u less the attacker knew an exact merchant that was unfortunately=
 on
<br>&gt; the minority of the network.=C2=A0
<br><br>Actually, just to take this scenario more explicitly...
<br><br>Say you've got 5% of hashpower running on old software, along with,=

<br>say, 1500 nodes; and meanwhile you've got 95% of hashpower running new
<br>software, along with 4000 nodes.
<br><br>There's still about 750 nodes running 0.9 or 0.8 of 5400 total =
according
<br>to bitnodes.21.co/nodes, so those numbers seems at least plausible to
<br>me for the first week or two after a soft-fork is activated.
<br><br>Eventually an old-rules block gets found by the 5% hashpower. The =
4000
<br>new nodes and 95% of hashpower ignore it, of course. With 8 random
<br>connections, old nodes should have 92% chance of seeing an old node
<br>as a peer, so I think around ~1300 of them should still be a connected
<br>subgraph, and the old-rules block should get propogated amongst them
<br>(until two new-rules blocks come along and orphan it).
<br><br>An SPV client with 12 random connections here has 96% chance of =
having one
<br>of the ~1300 old nodes as a peer, and if so, will see the old-rules =
block,
<br>that will be orphaned, and may be at risk from double-spends as a =
result.
<br><br>So I think even with just 5% hashpower and ~30% of nodes left =
running
<br>the old version, a =22damaging soft fork=22 still poses a fairly high =
risk to
<br>someone receiving payments via an SPV client, and trusting =
transactions
<br>with few confirmations.
<br><br>Cheers,
<br>aj
<br>=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
<br>bitcoin-dev mailing list
<br>bitcoin-dev@lists.linuxfoundation.org
<br>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<br></p></blockquote></div><br>
------Nodemailer-0.5.0-?=_1-1444694929051--