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 D6FD567 for ; Mon, 12 Oct 2015 07:02:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f179.google.com (mail-qk0-f179.google.com [209.85.220.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A3F1E87 for ; Mon, 12 Oct 2015 07:02:52 +0000 (UTC) Received: by qkas79 with SMTP id s79so55188736qka.0 for ; Mon, 12 Oct 2015 00:02:52 -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=5UBrHW7mFLyANAVD3ApxhOA5Gm29cdQoiVkJt/Cwsx8=; b=Q8pUsDXHTRX/wIxlM3X6b+tMbj2Ez4ZBvtJNyFqymL25mAHSzzeB8AhSOCj+XoEyg5 MSsMHEOcCPRp74paYLKhEFZH/misSfOBkbbdYKXrAuO0v98x/Wu1H136kE7kZj3dBuQC M0zBNgP85Esmd1y84K11pz7sxCx6T1V1i0FjaS9iz5zkGaehctJnsv7DqM0FdataNJQr MMJPe4THDRECpdTUOxsaNqkaBaL9ddh8CzGVEu+fKtkPLAZta6EKpuqIxw5GHEQ7Lz4o jnC/sdvt2lNIVRo/6mqGYSewZ8ERDbuuCuFq9glFTI7bV6p4Nz28vY3cJmcYJcrIlVtv YFng== X-Received: by 10.55.16.71 with SMTP id a68mr30320810qkh.95.1444633371905; Mon, 12 Oct 2015 00:02:51 -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 s87sm5395218qkl.5.2015.10.12.00.02.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Oct 2015 00:02:51 -0700 (PDT) Date: Mon, 12 Oct 2015 00:02:51 -0700 (PDT) X-Google-Original-Date: Mon, 12 Oct 2015 07:02:50 GMT MIME-Version: 1.0 X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) Message-Id: <1444633370859.8a298e9c@Nodemailer> In-Reply-To: <20151007150014.GA21849@navy> References: <20151007150014.GA21849@navy> X-Orchestra-Oid: 4696BF88-304D-4BD6-9E6C-CABB1ABD1301 X-Orchestra-Sig: 4a272ada9788058c6f59ddb3b9f0bec23c7a550d X-Orchestra-Thrid: TD56C876D-E76D-40BE-ACDA-81C322724964_1514188637025508290 X-Orchestra-Thrid-Sig: 220f0a8934cbc01363a0589b0c2f86c063b6bea8 X-Orchestra-Account: 83cdfba2f0b5e03358d5f5ca4b9224792eb26aca From: digitsu@gmail.com To: "Anthony Towns" Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1444633371062" 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: Mon, 12 Oct 2015 07:02:54 -0000 ------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
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.=  

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

-- snip --
 - non-upgraded bitcoin nodes: total breakage. there will be a = push
   alert telling you to upgrade. anyone who doesn't will = think they're
   tracking =22bitcoin=22 but will actually be tracking a = new =22bitcoin-old=22
   altcoin. most non-upgraded miners will presumably realise= they're
   wasting hashpower and stop doing this pretty quick; and = remaining
   miners will only create blocks very slowly due to sudden = reduced
   hashpower, without possibility of difficulty adjustment.=  
----

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 

----snip---
users who
   don't uprade will try to do transactions, but won't see = them confirm
   for 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. 


— Regards,
------Nodemailer-0.5.0-?=_1-1444633371062--