From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 86602267 for ; 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 ; Tue, 13 Oct 2015 00:08:50 +0000 (UTC) Received: by qgt47 with SMTP id 47so1530037qgt.2 for ; 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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--