Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B6EC8B30 for ; Thu, 13 Jul 2017 03:11:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f171.google.com (mail-qt0-f171.google.com [209.85.216.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2A037AD for ; Thu, 13 Jul 2017 03:11:37 +0000 (UTC) Received: by mail-qt0-f171.google.com with SMTP id i2so28092531qta.3 for ; Wed, 12 Jul 2017 20:11:37 -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=5MpO2g21Wlu2F3upZ+dGMcwH9dU6ITN19fEL/0tXJfk=; b=jp0pEDC3YKAYfzZQmelpQgPRwbpm7w+wQqDnXoDdDBwsiWaAV5tUxUiEZ4xKOlC8ol Q8/IrWK2DDDs2BoF0/ZxjQligW3kuMFK4tY6nLr4t/5pgg0CHijVkIWhwjPGqo/ha6zG FpEEqPCbUhua/e1SlCoN1RSf8UlwFWxzeqhFhai7OW/+cDJX9uo6mv06s8tNkfMj1SdD BbQ/Nwb5dmwKq5aWBYDpu9IfZdd6mdp1hFHWlPRk9Rp90YNV6jKrBW1TkNK2OQSATWDw 9f9oq9BkV1xysk8El2RlqfoYbLs4j5Xsq0fQl98yzm4W8DJ7bj+jVqdLCloHtJm79D+o AsAg== 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=5MpO2g21Wlu2F3upZ+dGMcwH9dU6ITN19fEL/0tXJfk=; b=WuOrNfiz2PmGf77M5Dg8QL92D8fi6GoEHGdvzOUvl12dRd7+ql4czwjwrTAcHXmTqY z6e8Ya/yJlsIPVphKeO/O0+v8brOwqOyTAOwiierfwIxDSgQplvfcdyFEKGGRfm0sR5q 6YqR7AzW8tk/9semcOLcKuy96MyLH5qmpavmDCKlik2/JIZmXHbUZMaXsNLAocQgfe27 KPxD4FJ0PuZVZrDEuaQdU2UQClQDRSSxDQkO3tN47vbgLmIEPsXDeS28BrVUzAO4afKr 9/Z8EiZ8cya1rMuerWOYUQEyjL6sqEC9WgM6WseOfxvCr1AObwlBHwwFL1X9AI9r4ge+ Gq1Q== X-Gm-Message-State: AIVw113udbyeKz8TIhmZT9AV/nZdq5wmJOhvp6V98bdEvQpn1uHiE8OY cva/hNuHur4lT2HHpQxqMGmDfYuOYikxMT0= X-Received: by 10.200.3.132 with SMTP id t4mr2304497qtg.232.1499915496322; Wed, 12 Jul 2017 20:11:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.135.113 with HTTP; Wed, 12 Jul 2017 20:10:55 -0700 (PDT) In-Reply-To: References: From: Sergio Demian Lerner Date: Thu, 13 Jul 2017 00:10:55 -0300 Message-ID: To: Gregory Maxwell Content-Type: multipart/alternative; boundary="f40304379a4859fc8f05542a4a00" 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:27 +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:11:37 -0000 --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
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 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.

There are several v= iable soft-forking solutions to it:

1- Soft-fork t= o 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)
<= div>3- Soft-fork to perform periodic reductions in the=C2=A0amount of data = hashed by non-segwit checksigs.

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.

,=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 c= ase in the BIP.=C2=A0

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



> 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 th= e rpc mining interface (getblocktemplate). It must be redefined, even if it= 's not a consensus change.


--f40304379a4859fc8f05542a4a00--