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 BE86E282 for ; Tue, 21 Jul 2015 18:09:21 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 101AA1B0 for ; Tue, 21 Jul 2015 18:09:21 +0000 (UTC) Received: by lbbqi7 with SMTP id qi7so40956841lbb.3 for ; Tue, 21 Jul 2015 11:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GbO2zG/5ZXAXmUfldTBrXr7MlR+4IJmddMlJjKtneTY=; b=ZpvmHIcKvuCyidBrrv2BDAMxSij7t89GhzxnbVbZF6oEccZygMpgsDqlwDAQc8jVJX i1LtmGlLeqS4EqiAdUWAmFHnYpa8rpbA1Bdz31gjn2aUOCfwk53LCpzOntws3VnnCIuJ 7Q/0D51RLg5GldnOCC4h1/CNzFRJZAA3yTV2JwMRq+S1vidUIWT8S0rFnpxQBgS+9FH3 3pPK8rodUs0DollV3C8SIOisc0h7IMYuZhxuvA7zna0kQWEzYrvhmkqOhKbGnocuv+Yu 7y+6dGMCNqkRaICNx/LsyNCvmIeCOV22dkKwb3hPVRWesJ2h6liPiLjIxP1OhsAoI9wX 53fQ== MIME-Version: 1.0 X-Received: by 10.112.55.70 with SMTP id q6mr30032576lbp.99.1437502159491; Tue, 21 Jul 2015 11:09:19 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Tue, 21 Jul 2015 11:09:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Jul 2015 14:09:19 -0400 Message-ID: From: Gavin Andresen To: Gregory Maxwell Content-Type: multipart/alternative; boundary=001a1133d13c949aa4051b668d59 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] For discussion: limit transaction size to mitigate CVE-2013-2292 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 18:09:21 -0000 --001a1133d13c949aa4051b668d59 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell wrote: > On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev > wrote: > > Mitigate a potential CPU exhaustion denial-of-service attack by limiting > > the maximum size of a transaction included in a block. > > This seems like a fairly indirect approach. The resource being watched > for is not the size (otherwise two transactions for 200k would be > strictly worse than one 200k transactions) but the potential of N^2 > costs related to repeated hashing in checksig; which this ignores. > Yes. The tradeoff is implementation complexity: it is trivial to check transaction size, not as trivial to count signature operations, because number-of-bytes-in-transaction doesn't require any context. But I would REALLY hate myself if in ten years a future version of me was struggling to get consensus to move away from some stupid 100,000 byte transaction size limit I imposed to mitigate a potential DoS attack. So I agree, a limit on sigops is the right way to go. And if that is being changed, might as well accurately count exactly how many sigops a transaction actually requires to be validated... -- -- Gavin Andresen --001a1133d13c949aa4051b668d59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jul 20, 2015 at 4:55 PM, Gregory Maxwell <gmaxwell@gmail.com>= wrote:
On Mon, J= ul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> Mitigate a potential CPU exhaustion denial-of-service attack by limiti= ng
> the maximum size of a transaction included in a block.

This seems like a fairly indirect approach. The resource being watch= ed
for is not the size (otherwise two transactions for 200k would be
strictly worse than one 200k transactions) but the potential of N^2
costs related to repeated hashing in checksig; which this ignores.

Yes.=C2=A0 The tradeoff is implementation compl= exity: it is trivial to check transaction size,
not as trivial to= count signature operations, because number-of-bytes-in-transaction
doesn't require any context.

But I would RE= ALLY hate myself if in ten years a future version of me was struggling to
get consensus to move away from some stupid 100,000 byte transacti= on size limit
I imposed to mitigate a potential DoS attack.
=

So I agree, a limit on sigops is the right way to go. A= nd if that is being changed,
might as well accurately count exact= ly how many sigops a transaction actually
requires to be validate= d...

--
--
= Gavin Andresen

--001a1133d13c949aa4051b668d59--