Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6DFD3AC9 for ; Wed, 13 Sep 2017 13:24:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CAFCF124 for ; Wed, 13 Sep 2017 13:24:36 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id i189so6736616wmf.1 for ; Wed, 13 Sep 2017 06:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-io.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=BcXnsI21pyYJTSuNCbZ1xpmttbIOv5qxA+W4joo4E18=; b=YAhAi6QEMo+kCODSwkNgnF15Q8mKDGHZe989kK3qrcr31k1Lcj/QA0tcKjirqLjOFG mC+1862RD17Z507GgKQWbgY+/N9w81/Y0+35Fza5jISE2r9IFdxn5TruZewQhU0VYPjy jXony49H1GH8eEQ8qkbbgRwQ/jTY6IeEN+l34NoYzbqJJC12xsx3LrPVxB9T0d103elP y+kNJSeJwlHhNJhJ87QXXVhFfJZgImeuExPxoIS28JmLd2PbJMX/jPWWKogzpV81aBMP GWhjgzdyHzhHvwpRz+NIdptdNLum5XaPLmzvIUVIVN2X0WvmrU9Q53TicuHZDfudK68f LYmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=BcXnsI21pyYJTSuNCbZ1xpmttbIOv5qxA+W4joo4E18=; b=i03cooRbdWqtsxzz3ApL44K+bjopVo2MATJCx3ZuWQF14G0xNGxG3HT6LNIDlWa4j+ DsFdoRSQfhsNjYA+gCBntaotkGKjFXO+VJ7RpflzZtwQA0zOyOBaFgkRycnOdwsuC5C+ ULeDeKmWXBY9mKeY1OP5JGNGwxK2ywpevZEHuTnB65yuo/E5N5DoM8GyTwvh9CdtkrpJ mQoUUaDQeEY3dWSIl1a0LqWXWOtIRl9mbvxQFuLHFUvceU8Ygl0Hil3HiPBctlFp9B0E GVf/RwI0nBvsZ12FSYbMDZB3KabqgWtlrri0t+snAS3fHobbOqz217otoZVZWdNSD2ey dSjg== X-Gm-Message-State: AHPjjUiBGLfytLbxKhNAXAB2JtSiCbzWRZnrGgPnJFr01FsaeqRT1Hx7 g5+HgdLVbpCYUGT+GSKsouYYx2DB45Fgk/ZrL5D6tw== X-Google-Smtp-Source: AOwi7QDGZSeVm/af5de6/SldFVe805oZ4Sld1WF65kheJLdRry4TzNQHiGvagfEEDKEVfbemZ6vgjp8OjZn3Ai+3Kxw= X-Received: by 10.28.7.83 with SMTP id 80mr2453331wmh.158.1505309075271; Wed, 13 Sep 2017 06:24:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.74.155 with HTTP; Wed, 13 Sep 2017 06:24:14 -0700 (PDT) From: "Russell O'Connor" Date: Wed, 13 Sep 2017 09:24:14 -0400 Message-ID: To: Mark Friedenbach , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="001a11443776b58e4905591214a0" X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] SigOps limit. 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: Wed, 13 Sep 2017 13:24:37 -0000 --001a11443776b58e4905591214a0 Content-Type: text/plain; charset="UTF-8" On Tue, Sep 12, 2017 at 3:57 PM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 4MB of secp256k1 signatures takes 10s to validate on my 5 year old > laptop (125,000 signatures, ignoring public keys and other things that > would consume space). That's much less than bad blocks that can be > constructed using other vulnerabilities. If there were no sigops limits, I believe the worst case block could have closer to 1,000,000 CHECKSIG operations. Signature checks are cached so while repeating the sequence "2DUP CHECKSIGVERIFY" does create a lot of checksig operations, the cached values prevent a lot of work being done. To defeat the cache one can repeat the sequence "2DUP CHECKSIG DROP CODESEPARATOR", which will create unique signature validation requests every 4 bytes. --001a11443776b58e4905591214a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Sep 12, 2017 at 3:57 PM, Mark Friedenbach via bitc= oin-dev <bitcoin-dev@lists.linuxfoundation.org>= wrote:

4MB of secp256k1 signatures takes 10s to validate on my 5 year old laptop (125,000 signatures, ignoring public keys and other things that
would consume space). That's much less than bad blocks that can be
constructed using other vulnerabilities.

If= there were no sigops limits, I believe the worst case block could have clo= ser to 1,000,000 CHECKSIG operations.=C2=A0 Signature checks are cached so = while repeating the sequence "2DUP CHECKSIGVERIFY" does create a = lot of checksig operations, the cached values prevent a lot of work being d= one.

To defeat the cache one can repeat the sequen= ce "2DUP CHECKSIG DROP CODESEPARATOR", which will create unique s= ignature validation requests every 4 bytes.
--001a11443776b58e4905591214a0--