path: root/50/3373867bde6913569e14a1edb7b7900efdc67d

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 86602267
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 13 Oct 2015 00:08:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com
	[209.85.192.47])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8EE51116
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 13 Oct 2015 00:08:50 +0000 (UTC)
Received: by qgt47 with SMTP id 47so1530037qgt.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 12 Oct 2015 17:08:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:mime-version:message-id:in-reply-to:references:from:to:cc
	:subject:content-type;
	bh=sj6S+QupAhXsW7CA2iW2KiJ98moiGvND6sJjpzmtFgs=;
	b=b88+7u+E4Zwva2frpukAQ6q2ckOJHs147URXCavK1Q9rzTpKqvAzAs3lK0f1v/vvdq
	u4VeUVT9GnckZfgPTsl86ERpJZX6c1FnykOEckAOv0QEhVr1XO8+f/3M1skwPLZnToRk
	031rot41R1h6gHiosphVgPzD2In4lrwMNabZWE7GoSrjslZPyn+gNem6oJSMtv7zlSBP
	+aWxT2SccZwANjC0zJAvwVGa6gAhRBIR8ty+YNR7YBpsE40vo7KdgGnCvsGBFLP3goHB
	3Q/mLC0Mg/DFvh8eEqkrK9t9FDMkj32SJJqle9UvEUnooVjLrw9UYdqQ6lfLrJfoAuAz
	3OoA==
X-Received: by 10.140.132.209 with SMTP id 200mr37878411qhe.64.1444694929840; 
	Mon, 12 Oct 2015 17:08:49 -0700 (PDT)
Received: from hedwig-18.prd.orcali.com
	(ec2-54-85-253-144.compute-1.amazonaws.com. [54.85.253.144])
	by smtp.gmail.com with ESMTPSA id m26sm96581qki.28.2015.10.12.17.08.48
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Mon, 12 Oct 2015 17:08:49 -0700 (PDT)
Date: Mon, 12 Oct 2015 17:08:49 -0700 (PDT)
X-Google-Original-Date: Tue, 13 Oct 2015 00:08:48 GMT
MIME-Version: 1.0
X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/)
Message-Id: <1444694928847.16a3b127@Nodemailer>
In-Reply-To: <20151012170637.GA21399@navy>
References: <20151012170637.GA21399@navy>
X-Orchestra-Oid: E656B08F-5A58-4CB9-995A-644E8457C643
X-Orchestra-Sig: 4a9319d7bf32f87bf290485a24dc38a2a034d02f
X-Orchestra-Thrid: TD56C876D-E76D-40BE-ACDA-81C322724964_1514188637025508290
X-Orchestra-Thrid-Sig: 220f0a8934cbc01363a0589b0c2f86c063b6bea8
X-Orchestra-Account: fc859c781d71c6837b90cc6f0296c74901d9233b
From: digitsu@gmail.com
To: "Anthony Towns" <aj@erisian.com.au>
Content-Type: multipart/alternative;
	boundary="----Nodemailer-0.5.0-?=_1-1444694929051"
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
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: Tue, 13 Oct 2015 00:08:51 -0000

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