MIME-Version: 1.0
In-Reply-To: <CAAS2fgRAdKFu8JqbmtAES3NkX2BK27LucSf=heZ2xyz30BKetw@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
	<CAAS2fgRAdKFu8JqbmtAES3NkX2BK27LucSf=heZ2xyz30BKetw@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Thu, 13 Jul 2017 00:10:55 -0300
Message-ID: <CAKzdR-pkiWXuZKH1NLR_=OD+NUGxzOgX03beJ7pc1QGVdmg3VA@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary="f40304379a4859fc8f05542a4a00"
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Segwit2x BIP
Precedence: list

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

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.


>

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Some responses..=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">
<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><div>I think that limiting the maximum tran=
saction size may not be the best possible solution to the N^2 hashing probl=
em, yet it is not a bad start.</div><div><br></div><div>There are several v=
iable soft-forking solutions to it:</div><div><br></div><div>1- Soft-fork t=
o perform periodic reductions in the maximum non-segwit checksigs per input=
 (down to 20)<br></div><div>2- Soft-fork to perform periodic reductions 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 of data =
hashed by non-segwit checksigs.</div><div><br></div><div>Regardless which o=
ne 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 c=
iting this vulnerability.</div><div><br></div><div>,=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid 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><div>I will mention this worst c=
ase 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 p=
roblem 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 bytes) dis=
count 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 ne=
ed to incentivize removing the signatures from blocks, because there is alr=
eady an incentive to do so to save disk space.</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><br>
<span class=3D"gmail-"><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"gmail-"><br></span></blockquote><div>No, it is exposed to th=
e rpc mining interface (getblocktemplate). It must be redefined, even if it=
&#39;s not a consensus change.</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><br></blockquote></div></div></div>

--f40304379a4859fc8f05542a4a00--