path: root/21/d131f8be851b0a9a5106f5b0157992eb3ad3db

Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5E612B30
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Jul 2017 03:20:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com
	[209.85.220.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C456510A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 13 Jul 2017 03:20:09 +0000 (UTC)
Received: by mail-qk0-f180.google.com with SMTP id d78so40540496qkb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Jul 2017 20:20:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=U0le+QZe0mIoAJ+5mns57PdQD6RGiblGWikNUhSmOT0=;
	b=V2sVmNn8xJmY7UcDIr7z3P2zW/Hz9ef18ipRWVmVhH6BsU8VaWSG3FIN+whARQaBWM
	ivJDnhuvgf8Qz1BmRzlTxfoLkE7JJeZjb2UepjowWbUZFqUsdwDhwVY/bRjZ9lh8B6tB
	/1Ns0nBUamqzumw1otWxQKu8VTXXDknOlWTnq6Z0TSbgX/xiGQzUc/1FNT+Wlb1exFn6
	8xaZOQHV5SviW7sTh3MEHSjFBvt9OskJVYArF0+ChX5+XP9GHqIenn2AUnpyGCKkt+bb
	WBPQj3j0TewieOlLraU+xJF3tgzlYLVtER4ilWM7h8UecGCKG52lubWk4Txlu9aFeeQ+
	bgnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=U0le+QZe0mIoAJ+5mns57PdQD6RGiblGWikNUhSmOT0=;
	b=GNpF5GvYkrlM0Vn9OkVhSGlr2KYfL/rZYOahs+fvmDUSwlOE41SuVuW8UmoFCrSpKR
	bjoH1MdPPtPG3Ziw4EEdfesKMwMsla2AiibFS8s1pqXjOir4DEcNb55P4D4wJkvZ+kBu
	eIYdsdncixUJledmApPet3zqHnI8E8awKhWNWSnRL7J48gXACrKs3SaG3eK81fJw4vYy
	9n0//4tTJGR6OjxlHi+5R65xc8z6rJC2Zoy2ncw3F8+xSzZiIZ3AAOzgzhhO2Liy5UnY
	q0BDpXN1r05CtcHt12s/R81ygWYnuW2RjTdWH0uRbhhviw2X4xJvje91uSkBV04MwKcm
	6dEg==
X-Gm-Message-State: AIVw112o3pI3Psv09jEZgVfFf/mKfZDQyZnXpODZG6/YzONqGCCvddH1
	QlwxUh/P9p79BDmIP6GA2DaIKgQgAA==
X-Received: by 10.55.43.160 with SMTP id r32mr2087556qkr.47.1499916009034;
	Wed, 12 Jul 2017 20:20:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.135.113 with HTTP; Wed, 12 Jul 2017 20:19:28 -0700 (PDT)
In-Reply-To: <CAKzdR-pkiWXuZKH1NLR_=OD+NUGxzOgX03beJ7pc1QGVdmg3VA@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CAAS2fgRAdKFu8JqbmtAES3NkX2BK27LucSf=heZ2xyz30BKetw@mail.gmail.com>
	<CAKzdR-pkiWXuZKH1NLR_=OD+NUGxzOgX03beJ7pc1QGVdmg3VA@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Thu, 13 Jul 2017 00:19:28 -0300
Message-ID: <CAKzdR-oW9gq=pbCGSqehSR2cp2NP+4v82KGVwbV9TbNnzmQb2Q@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary="001a11495ff6e95b1305542a6869"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE, 
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 13 Jul 2017 03:20:52 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Segwit2x BIP
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Thu, 13 Jul 2017 03:20:10 -0000

--001a11495ff6e95b1305542a6869
Content-Type: text/plain; charset="UTF-8"

Well, 40 bytes reduction per input is excessive too :)
But 30 bytes reduction will do fine.

On Thu, Jul 13, 2017 at 12:10 AM, Sergio Demian Lerner <
sergio.d.lerner@gmail.com> wrote:

> Some responses..
>
>>
>> The proposal adds another gratuitous limit to the system: A maximum
>> transaction size where none existed before, yet this limit is almost
>> certainly too small to prevent actual DOS attacks while it is also
>> technically larger than any transaction that can be included today
>> (the largest possible transaction today is 1mb minus the block
>> overheads).  The maximum resource usage for maliciously crafted 1MB
>> transaction is enormous and permitting two of them greatly exacerbates
>> the existing vulnerability.
>>
>>
> I think that limiting the maximum transaction size may not be the best
> possible solution to the N^2 hashing problem, yet it is not a bad start.
>
> There are several viable soft-forking solutions to it:
>
> 1- Soft-fork to perform periodic reductions in the maximum non-segwit
> checksigs per input (down to 20)
> 2- Soft-fork to perform periodic reductions in the number of non-segwit
> checksigs per transaction. (down to 5K)
> 3- Soft-fork to perform periodic reductions in the amount of data hashed
> by non-segwit checksigs.
>
> Regardless which one one picks, the soft-fork can be deployed with enough
> time in advance to reduce the exposure. The risk is still low. Four years
> have passed since I reported this vulnerability and yet nobody has
> exploited it. The attack is highly anti-economical, yet every discussion
> about the block size ends up citing this vulnerability.
>
> ,
>
>> > Assuming the current transaction pattern is replicated in a 2 MB
>> plain-sized block that is 100% filled with transactions, then the
>> witness-serialized block would occupy 3.6 MB
>>
>> But in a worst case the result would be 8MB, which this document fails
>> to mention.
>>
>
> I will mention this worst case in the BIP.
>
> Even if artificially filling the witness space up to 8 MB is
> anti-economical, Segwit exacerbates this problem because each witness byte
> costs 1/4th of a non-witness byte, so the block bloat attack gets cheaper
> than before. I think the guilt lies more in Segwit discount factor than in
> the plain block size increase.
> I would remove the discount factor altogether, and add a fixed (40 bytes)
> discount for each input with respect to outputs (not for certain input
> types), to incentivize the cleaning of the UTXO set. A discount for inputs
> cannot be used to bloat an unlimited number of blocks, because for each
> input the attacker needs to first create an output (without discount).
> There is no need to incentivize removing the signatures from blocks,
> because there is already an incentive to do so to save disk space.
>
>
>>
>> > Deploy a modified BIP91 to activate Segwit. The only modification is
>> that the signal "segsignal" is replaced by "segwit2x".
>>
>> This means that BIP-91 and your proposal are indistinguishable on the
>> network, because the string "segsignal" is merely a variable name used
>> in the software.
>>
>> No, it is exposed to the rpc mining interface (getblocktemplate). It must
> be redefined, even if it's not a consensus change.
>
>
>>

--001a11495ff6e95b1305542a6869
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Well, 40 bytes reduction per input is excessive too :)=C2=
=A0<div>But 30 bytes reduction will do fine.</div></div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Thu, Jul 13, 2017 at 12:10 AM, Se=
rgio Demian Lerner <span dir=3D"ltr">&lt;<a href=3D"mailto:sergio.d.lerner@=
gmail.com" target=3D"_blank">sergio.d.lerner@gmail.com</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote"><div>Some responses..=C2=A0</div><span clas=
s=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
The proposal adds another gratuitous limit to the system: A maximum<br>
transaction size where none existed before, yet this limit is almost<br>
certainly too small to prevent actual DOS attacks while it is also<br>
technically larger than any transaction that can be included today<br>
(the largest possible transaction today is 1mb minus the block<br>
overheads).=C2=A0 The maximum resource usage for maliciously crafted 1MB<br=
>
transaction is enormous and permitting two of them greatly exacerbates<br>
the existing vulnerability.<br>
<br></blockquote><div><br></div></span><div>I think that limiting the maxim=
um transaction size may not be the best possible solution to the N^2 hashin=
g problem, yet it is not a bad start.</div><div><br></div><div>There are se=
veral viable soft-forking solutions to it:</div><div><br></div><div>1- Soft=
-fork to perform periodic reductions in the maximum non-segwit checksigs pe=
r input (down to 20)<br></div><div>2- Soft-fork to perform periodic reducti=
ons in the number of non-segwit checksigs per transaction. (down to 5K)<br>=
</div><div>3- Soft-fork to perform periodic reductions in the=C2=A0amount o=
f data hashed by non-segwit checksigs.</div><div><br></div><div>Regardless =
which one one picks, the soft-fork can be deployed with enough time in adva=
nce to reduce the exposure. The risk is still low. Four years have passed s=
ince I reported this vulnerability and yet nobody has exploited it. The att=
ack is highly anti-economical, yet every discussion about the block size en=
ds up citing this vulnerability.</div><div><br></div><div>,=C2=A0</div><spa=
n class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; Assuming the current transaction pattern is replicated in a 2 MB plain=
-sized block that is 100% filled with transactions, then the witness-serial=
ized block would occupy 3.6 MB<br>
<br>
But in a worst case the result would be 8MB, which this document fails<br>
to mention.<br></blockquote><div><br></div></span><div>I will mention this =
worst case in the BIP.=C2=A0</div><div><br></div><div>Even if artificially =
filling the witness space up to 8 MB is anti-economical, Segwit exacerbates=
 this problem because each witness byte costs 1/4th of a non-witness byte, =
so the block bloat attack gets cheaper than before. I think the guilt lies =
more in Segwit discount factor than in the plain block size increase.</div>=
<div>I would remove the discount factor altogether, and add a fixed (40 byt=
es) discount for each input with respect to outputs (not for certain input =
types), to incentivize the cleaning of the UTXO set. A discount for inputs =
cannot be used to bloat an unlimited number of blocks, because for each inp=
ut the attacker needs to first create an output (without discount). There i=
s no need to incentivize removing the signatures from blocks, because there=
 is already an incentive to do so to save disk space.</div><span class=3D""=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<span class=3D"m_-8986009842530904450gmail-"><br>
&gt; Deploy a modified BIP91 to activate Segwit. The only modification is t=
hat the signal &quot;segsignal&quot; is replaced by &quot;segwit2x&quot;.<b=
r>
<br>
</span>This means that BIP-91 and your proposal are indistinguishable on th=
e<br>
network, because the string &quot;segsignal&quot; is merely a variable name=
 used<br>
in the software.<br>
<span class=3D"m_-8986009842530904450gmail-"><br></span></blockquote></span=
><div>No, it is exposed to the rpc mining interface (getblocktemplate). It =
must be redefined, even if it&#39;s not a consensus change.</div><div><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote></d=
iv></div></div>
</blockquote></div><br></div>

--001a11495ff6e95b1305542a6869--