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 D1C7EE2B for ; 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 ; Fri, 18 Dec 2015 03:02:38 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id q3so32504772pav.3 for ; 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" To: "Jonathan Toomim" , "Pieter Wuille" Date: Fri, 18 Dec 2015 03:02:36 +0000 Message-Id: In-Reply-To: Reply-To: "Eric Lombrozo" 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 To: "Pieter Wuille" Cc: "Bitcoin Dev" 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 > 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
First of all, that's an expensive beer!
 
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).
 
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...)
 
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.
 
- Eric
 
------ Original Message ------
From: "Jonathan Toomim via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org>= ;
To: "Pieter Wuille" <pie= ter.wuille@gmail.com>
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 <bitcoin-dev@lists.lin= uxfoundation.org> wrote:

1) The risk of an old full node wallet acce= pting a transaction that is
invalid to the new rules= .

The receiver wallet chooses = what address/script to accept coins on.
They'll upgra= de to the new softfork rules before creating an address
= that depends on the softfork's features.
<= 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">So, not a problem.

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.

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;

Mallory gets free beer.

Anything I'm missing?
--------=_MB5BED5328-D5EE-4309-8CC3-05B819EFB065--