path: root/c6/d63025e531569ec7ff3a07648f0ecaa62cee2d

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>&nbsp;</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. &gt; 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&nbsp;in&nbsp;the use case&nbsp;(i.e. a web hosting provider that=
 can shut the user out if fraud is later detected).</DIV>
<DIV>&nbsp;</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>&nbsp;</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>&nbsp;</DIV>
<DIV>- Eric</DIV>
<DIV>&nbsp;</DIV>
<DIV>------ Original Message ------</DIV>
<DIV>From: "Jonathan Toomim via bitcoin-dev" &lt;<A href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</A>&gt=
;</DIV>
<DIV>To: "Pieter Wuille" &lt;<A href=3D"mailto:pieter.wuille@gmail.com">pie=
ter.wuille@gmail.com</A>&gt;</DIV>
<DIV>Cc: "Bitcoin Dev" &lt;<A href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org">bitcoin-dev@lists.linuxfoundation.org</A>&gt;</DIV>
<DIV>Sent: 12/17/2015 6:47:14 PM</DIV>
<DIV>Subject: Re: [bitcoin-dev] On the security of softforks</DIV>
<DIV>&nbsp;</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 &lt;<A =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.lin=
uxfoundation.org</A>&gt; 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--