Return-Path: <elombrozo@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D1C7EE2B for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 18 Dec 2015 03:02:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4E8AA110 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 18 Dec 2015 03:02:38 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id q3so32504772pav.3 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 17 Dec 2015 19:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version:content-type; bh=zuhS2XTz5Z1UsshuBhpRBF13QWvcLpPd8UD9eoCvcj0=; b=oUt7eXYjAo0Th5tQRQoMINLQoIoB9RqGDXKdXxOczPFld9q5bltwso063Mdhd69lVF 8xR17efPAyUoK+1zeXwFUmZU1JntvHXBHvlgw/46walqzxcGAtaydYuSffDR/vxTrzXP 6iDY1YepeMLTfCArpP1CtDUE3kpZMYZHSg/+2F4J/OWyI/Ib0O/WcZKDZqHD4u5iB4d9 Cyn0QZP8Lr06pnbFqfn/FZp+8YAkqiYqLK0WJdDjQG4GBQC+aej/w6wAeNMqa1WXJAJO zajZkRil7MLcsUhm8lt5hozNhOdvgQ9H90ExwAfz8uPpjbZJiEOQjFWkPE2Gjyc++0c3 IiyQ== X-Received: by 10.66.55.105 with SMTP id r9mr1678751pap.137.1450407758056; Thu, 17 Dec 2015 19:02:38 -0800 (PST) Received: from [192.168.1.108] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id f89sm14101855pfd.10.2015.12.17.19.02.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Dec 2015 19:02:37 -0800 (PST) From: "Eric Lombrozo" <elombrozo@gmail.com> To: "Jonathan Toomim" <j@toom.im>, "Pieter Wuille" <pieter.wuille@gmail.com> Date: Fri, 18 Dec 2015 03:02:36 +0000 Message-Id: <em9d607452-50c0-4aa2-941e-7b637a287a70@platinum> In-Reply-To: <E76D5BF9-41BF-4AF5-BBAC-06F4EF574EBE@toom.im> Reply-To: "Eric Lombrozo" <elombrozo@gmail.com> User-Agent: eM_Client/6.0.23181.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB5BED5328-D5EE-4309-8CC3-05B819EFB065" 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 <bitcoin-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] On the security of softforks 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: Fri, 18 Dec 2015 03:02:38 -0000 --------=_MB5BED5328-D5EE-4309-8CC3-05B819EFB065 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable First of all, that's an expensive beer! Second of all, any consensus rule change risks non-full-validating or=20 non-upgraded nodes seeing invalid confirmations...but assuming a large=20 supermajority (i.e. > 95%) of hashing power is behind the new rule, it=20 is extremely unlikely that very many invalid confirmations will ever be=20 seen by anyone. The number of confirmations you require depends on your=20 use case security requirements...and especially during a new rule=20 activation, it is probably not a good idea for non-validating nodes or=20 non-upgraded nodes to accept coins with low confirmation counts unless=20 the risk is accounted for in the use case (i.e. a web hosting provider=20 that can shut the user out if fraud is later detected). Third of all, as long as the rule change activation is signaled in=20 blocks, even old nodes will be able to detect that something is fishy=20 and warn users to be more cautious (i.e. wait more confirmations or=20 immediately upgrade or connect to a different node that has upgraded,=20 etc...) I honestly don't see an issue here - unless you're already violating=20 fundamental security assumptions that would make you vulnerable to=20 exploitation even without rule changes. - Eric ------ Original Message ------ From: "Jonathan Toomim via bitcoin-dev"=20 <bitcoin-dev@lists.linuxfoundation.org> To: "Pieter Wuille" <pieter.wuille@gmail.com> Cc: "Bitcoin Dev" <bitcoin-dev@lists.linuxfoundation.org> Sent: 12/17/2015 6:47:14 PM Subject: Re: [bitcoin-dev] On the security of softforks > >On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev=20 ><bitcoin-dev@lists.linuxfoundation.org> wrote: > >>1) The risk of an old full node wallet accepting a transaction that is >>invalid to the new rules. >> >>The receiver wallet chooses what address/script to accept coins on. >>They'll upgrade to the new softfork rules before creating an address >>that depends on the softfork's features. >> >>So, not a problem. > >Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob=20 >runs the old rules. Bob creates a p2pkh address for Mallory to use.=20 >Mallory takes 1 BTC, and creates an invalid SegWit transaction that Bob= =20 >cannot properly validate and that pays into one of Mallory's wallets.=20 >Mallory then immediately spends the unconfirmed transaction into Bob's=20 >address. Bob sees what appears to be a valid transaction chain which is= =20 >not actually valid. > >Clueless Carol is one of the 4.9% of miners who forgot to upgrade her=20 >mining node. Carol sees that Mallory included an enormous fee in his=20 >transactions, so Carol makes sure to include both transactions in her=20 >block. > >Mallory gets free beer. > >Anything I'm missing? --------=_MB5BED5328-D5EE-4309-8CC3-05B819EFB065 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <HTML><HEAD> <STYLE id=3DeMClientCss>blockquote.cite { margin-left: 5px; margin-right:= 0px; padding-left: 10px; padding-right:0px; border-left: 1px solid #cccccc= } blockquote.cite2 {margin-left: 5px; margin-right: 0px; padding-left: 10px;= padding-right:0px; border-left: 1px solid #cccccc; margin-top: 3px; paddin= g-top: 0px; } .plain pre, .plain tt { font-family: monospace; font-size: 100%; font-weigh= t: normal; font-style: normal; white-space: pre-wrap; } a img { border: 0px; }body {font-family: Tahoma;font-size: 12pt;} .plain pre, .plain tt {font-family: Tahoma;font-size: 12pt;} </STYLE> <STYLE></STYLE> </HEAD> <BODY scroll=3Dauto class> <DIV>First of all, that's an expensive beer!</DIV> <DIV> </DIV> <DIV>Second of all, any consensus rule change risks non-full-validating = or non-upgraded nodes seeing invalid confirmations...but assuming a large= supermajority (i.e. > 95%) of hashing power is behind the new rule, = it is extremely unlikely that very many invalid confirmations will ever = be seen by anyone. The number of confirmations you require depends on your= use case security requirements...and especially during a new rule activati= on, it is probably not a good idea for non-validating nodes or non-upgraded= nodes to accept coins with low confirmation counts unless the risk is acco= unted for in the use case (i.e. a web hosting provider that= can shut the user out if fraud is later detected).</DIV> <DIV> </DIV> <DIV>Third of all, as long as the rule change activation is signaled in = blocks, even old nodes will be able to detect that something is fishy and= warn users to be more cautious (i.e. wait more confirmations or immediatel= y upgrade or connect to a different node that has upgraded, etc...)</DIV> <DIV> </DIV> <DIV>I honestly don't see an issue here - unless you're already violating= fundamental security assumptions that would make you vulnerable to exploit= ation even without rule changes.</DIV> <DIV> </DIV> <DIV>- Eric</DIV> <DIV> </DIV> <DIV>------ Original Message ------</DIV> <DIV>From: "Jonathan Toomim via bitcoin-dev" <<A href=3D"mailto:bitcoin-= dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</A>>= ;</DIV> <DIV>To: "Pieter Wuille" <<A href=3D"mailto:pieter.wuille@gmail.com">pie= ter.wuille@gmail.com</A>></DIV> <DIV>Cc: "Bitcoin Dev" <<A href=3D"mailto:bitcoin-dev@lists.linuxfoundat= ion.org">bitcoin-dev@lists.linuxfoundation.org</A>></DIV> <DIV>Sent: 12/17/2015 6:47:14 PM</DIV> <DIV>Subject: Re: [bitcoin-dev] On the security of softforks</DIV> <DIV> </DIV> <DIV id=3Dx3e2d1b6db74e43a5a23c7578ce14d4e2 style=3D"WORD-WRAP: break-word;= -webkit-nbsp-mode: space; -webkit-line-break: after-white-space"> <BLOCKQUOTE class=3Dcite2 cite=3DE76D5BF9-41BF-4AF5-BBAC-06F4EF574EBE@toom.= im type=3D"cite"><BR> <DIV> <DIV>On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev <<A = href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.lin= uxfoundation.org</A>> wrote:</DIV><BR class=3DApple-interchange-newline> <BLOCKQUOTE class=3Dcite type=3D"cite"><SPAN style=3D"WHITE-SPACE: normal;= WORD-SPACING: 0px; TEXT-TRANSFORM: none; FLOAT: none; FONT: 12px Helvetica= ; DISPLAY: inline !important; LETTER-SPACING: normal; TEXT-INDENT: 0px; = -webkit-text-stroke-width: 0px">1) The risk of an old full node wallet acce= pting a transaction that is</SPAN><BR style=3D"WHITE-SPACE: normal; WORD-SP= ACING: 0px; TEXT-TRANSFORM: none; FONT: 12px Helvetica; LETTER-SPACING: = normal; TEXT-INDENT: 0px; -webkit-text-stroke-width: 0px"><SPAN style=3D= "WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FLOAT: none;= FONT: 12px Helvetica; DISPLAY: inline !important; LETTER-SPACING: normal;= TEXT-INDENT: 0px; -webkit-text-stroke-width: 0px">invalid to the new rules= .</SPAN><BR style=3D"WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM= : none; FONT: 12px Helvetica; LETTER-SPACING: normal; TEXT-INDENT: 0px; = -webkit-text-stroke-width: 0px"><BR style=3D"WHITE-SPACE: normal; WORD-SPAC= ING: 0px; TEXT-TRANSFORM: none; FONT: 12px Helvetica; LETTER-SPACING: norma= l; TEXT-INDENT: 0px; -webkit-text-stroke-width: 0px"><SPAN style=3D"WHITE-S= PACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FLOAT: none; FONT:= 12px Helvetica; DISPLAY: inline !important; LETTER-SPACING: normal; TEXT-I= NDENT: 0px; -webkit-text-stroke-width: 0px">The receiver wallet chooses = what address/script to accept coins on.</SPAN><BR style=3D"WHITE-SPACE: = normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FONT: 12px Helvetica; LETT= ER-SPACING: normal; TEXT-INDENT: 0px; -webkit-text-stroke-width: 0px"><SPAN= style=3D"WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; = FLOAT: none; FONT: 12px Helvetica; DISPLAY: inline !important; LETTER-SPACI= NG: normal; TEXT-INDENT: 0px; -webkit-text-stroke-width: 0px">They'll upgra= de to the new softfork rules before creating an address</SPAN><BR style=3D= "WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FONT: 12px= Helvetica; LETTER-SPACING: normal; TEXT-INDENT: 0px; -webkit-text-stroke-w= idth: 0px"><SPAN style=3D"WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRAN= SFORM: none; FLOAT: none; FONT: 12px Helvetica; DISPLAY: inline !important;= LETTER-SPACING: normal; TEXT-INDENT: 0px; -webkit-text-stroke-width: 0px">= that depends on the softfork's features.</SPAN><BR style=3D"WHITE-SPACE:= normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none; FONT: 12px Helvetica; = LETTER-SPACING: normal; TEXT-INDENT: 0px; -webkit-text-stroke-width: 0px"><= BR style=3D"WHITE-SPACE: normal; WORD-SPACING: 0px; TEXT-TRANSFORM: none;= FONT: 12px Helvetica; LETTER-SPACING: normal; TEXT-INDENT: 0px; -webkit-te= xt-stroke-width: 0px"><SPAN style=3D"WHITE-SPACE: normal; WORD-SPACING: = 0px; TEXT-TRANSFORM: none; FLOAT: none; FONT: 12px Helvetica; DISPLAY: inli= ne !important; LETTER-SPACING: normal; TEXT-INDENT: 0px; -webkit-text-strok= e-width: 0px">So, not a problem.</SPAN></BLOCKQUOTE></DIV> <DIV><BR></DIV> <DIV>Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob= runs the old rules. Bob creates a p2pkh address for Mallory to use. Mallor= y takes 1 BTC, and creates an invalid SegWit transaction that Bob cannot= properly validate and that pays into one of Mallory's wallets. Mallory = then immediately spends the unconfirmed transaction into Bob's address. = Bob sees what appears to be a valid transaction chain which is not actually= valid.</DIV> <DIV><BR></DIV> <DIV>Clueless Carol is one of the 4.9% of miners who forgot to upgrade her= mining node. Carol sees that Mallory included an enormous fee in his trans= actions, so Carol makes sure to include both transactions in her block.&nbs= p;</DIV> <DIV><BR></DIV> <DIV>Mallory gets free beer.</DIV> <DIV><BR></DIV> <DIV>Anything I'm missing?</DIV></BLOCKQUOTE></DIV></BODY></HTML> --------=_MB5BED5328-D5EE-4309-8CC3-05B819EFB065--