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 5E612B30 for ; 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 ; Thu, 13 Jul 2017 03:20:09 +0000 (UTC) Received: by mail-qk0-f180.google.com with SMTP id d78so40540496qkb.1 for ; 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: References: From: Sergio Demian Lerner Date: Thu, 13 Jul 2017 00:19:28 -0300 Message-ID: To: Gregory Maxwell 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
Well, 40 bytes reduction per input is excessive too :)=C2= =A0
But 30 bytes reduction will do fine.

On Thu, Jul 13, 2017 at 12:10 AM, Se= rgio Demian Lerner <sergio.d.lerner@gmail.com> wrote= :
Some responses..=C2=A0

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).=C2=A0 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 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.

There are se= veral viable soft-forking solutions to it:

1- Soft= -fork to perform periodic reductions in the maximum non-segwit checksigs pe= r input (down to 20)
2- Soft-fork to perform periodic reducti= ons in the number of non-segwit checksigs per transaction. (down to 5K)
=
3- Soft-fork to perform periodic reductions in the=C2=A0amount o= f data hashed by non-segwit checksigs.

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.

,=C2=A0
> 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

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.=C2=A0

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 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.



> Deploy a modified BIP91 to activate Segwit. The only modification is t= hat the signal "segsignal" is replaced by "segwit2x".
This means that BIP-91 and your proposal are indistinguishable on th= e
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.

<= /div>


--001a11495ff6e95b1305542a6869--