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 2E143475 for ; Thu, 23 Jul 2015 15:41:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DB955290 for ; Thu, 23 Jul 2015 15:41:19 +0000 (UTC) Received: by lbbyj8 with SMTP id yj8so160539597lbb.0 for ; Thu, 23 Jul 2015 08:41:18 -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=Mklv3/kF1eRfO+0XQCFy5NWqC5qEYrHzgqohofFiJgM=; b=IZNtafRSdP/zBKQVi3t/DI8bEuqbIRwnvsaDQFElI5KGa+Qf9f7szCd83u4iaDEDPn KnXE9MOPvtzXBseyvL8806kZK65nTuf9KTbvrYCbYvm/Ddp2F4tkq/HLFesSeNVZyEUF dn/G02DpOiJIdq0cgTfPh6iJMn/sShW9u1Od77rD0fnYn7jtjksdAOfa3Oq+b39UIVvM DTyNQEU8GlG2WYVlI+ErgDUW17CnLuNM9G+7xYYUGvfKt5xjFsFw1yFfTI3dvfyazER7 urEvxHkBSVgbYN8ChEVY0t0F4PatuC9AYI6rlxJjKNTuRZ1Wnb2Vfj3CVXniMmE9DqgE nVKA== MIME-Version: 1.0 X-Received: by 10.152.22.99 with SMTP id c3mr8918296laf.32.1437666078164; Thu, 23 Jul 2015 08:41:18 -0700 (PDT) Received: by 10.25.90.75 with HTTP; Thu, 23 Jul 2015 08:41:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Jul 2015 11:41:18 -0400 Message-ID: From: Gavin Andresen To: Gregory Maxwell Content-Type: multipart/alternative; boundary=089e0158b6c0e50ebf051b8cb72c 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: Thu, 23 Jul 2015 15:41:22 -0000 --089e0158b6c0e50ebf051b8cb72c 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. > To get a feeling for the implementation complexity / correctness tradeoff, I implemented changes to Core to count exactly how many signature operations are performed and how many bytes are hashed to compute sighashes: https://github.com/gavinandresen/bitcoin-git/commit/08ecd6f67d977271faa92bc1890b8f94b15c2792 I haven't benchmarked how much keeping track of the counts affects performance (but I expect it to be minimal compared to ECDSA signature validation, accessing inputs from the UTXO, etc). I like the idea of a consensus rule that directly addresses the attack-- e.g. "validating a transaction must not require more than X megabytes hashed to compute signature hashes." (or: "validating a block must not require more than X megabytes hashed..." which is more symmetric with the current "maximum number of sigops allowed per block") Thinking about this and looking at block 364,292, I think I see a simple optimization that would speed up validation for transactions with lots of inputs: use SIGHASH_ANYONECANPAY for all of the inputs instead of SIGHASH_ALL. (which would make the transaction malleable-- if that's a concern, then make one of the inputs SIGHASH_ALL and the rest SIGHASH_ANYONECANPAY-- I think this is a change that should be made to Core and other wallets should make). --- I'd like to hear from maintainers of other full implementations: how hard would it be for you to keep track of the number of bytes hashed to validate a transaction or block, and use it as a consensus rule? -- -- Gavin Andresen --089e0158b6c0e50ebf051b8cb72c 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.

To get a feeling for the implementation complex= ity / correctness tradeoff,
I implemented changes to Core to coun= t exactly how many signature operations
are performed and how man= y bytes are hashed to compute sighashes:

I haven= 9;t benchmarked how much keeping track of the counts affects performance (b= ut I expect
it to be minimal compared to ECDSA signature validati= on, accessing inputs from the UTXO, etc).

I like t= he idea of a consensus rule that directly addresses the attack-- e.g. "= ;validating
a transaction must not require more than X megabytes = hashed to compute signature hashes."
(or: "validating a= block must not require more than X megabytes hashed..." which is
more symmetric with the current "maximum number of sigops allowe= d per block")

Thinking about this and looking at block 364,292, I thin= k I see a simple optimization that would
sp= eed up validation for transactions with lots of inputs: =C2=A0use SIGHASH_A= NYONECANPAY
for all of the inputs instead o= f SIGHASH_ALL.

(which would make the transaction malleable-- if that's a conc= ern, then make one of the inputs
SIGHASH_AL= L and the rest SIGHASH_ANYONECANPAY-- I think this is a change that
should be made to Core and other wallets should ma= ke).

-= --

I&#= 39;d like to hear from maintainers of other full implementations: how hard = would it be for you
to keep track of the nu= mber of bytes hashed to validate a transaction or block, and use
it as a consensus rule?

--
--
Gavin Andresen

--089e0158b6c0e50ebf051b8cb72c--