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 E29E6FF7 for ; Sat, 17 Feb 2018 02:33:34 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3AF62D3 for ; Sat, 17 Feb 2018 02:33:34 +0000 (UTC) Received: by mail-vk0-f45.google.com with SMTP id x135so1243146vkd.5 for ; Fri, 16 Feb 2018 18:33:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=GhyXd5p6rEf9sR+/Vkr9I+A2jv350x1HoEZIoZprGZU=; b=r0N8tOV5uebqDAkkxBKu38ku6uYhetZOufPQQx+m86qMQcfYHnkhIw77s9sDXFxJAf BRL35OU4u1tvszkwlXdYTQhwJwHi7K4sD0/dSdZM5XTTqZKwnz1SjKWIgNPQ8LM/5mBj KDPv5tj7rKIZAgsYBV3Bhuo1M0pRNF706GAboWjrq6ozUIOU7OKX3W3qUFrljibAnGsJ 4VLnnRQsBcGmoR3IPMOEP4h0Y+t9qXN8NvuwnZG+SLia4L3dQnbNGLhncYBCOHKACdfe PjO1Cmv5TJb+m6gUEwkiMhyZOlcrW4UNcM78Hi/amIl/KumctGGCleTgVL5C3bcNDvax 40ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=GhyXd5p6rEf9sR+/Vkr9I+A2jv350x1HoEZIoZprGZU=; b=NV1yW0rVI2QEQzpwtQAOgXerGiTWJN/yz04gmqiGtx0j2+Q0xp496Zp2Ik/oB7jDlu 1BBYbYa5zbD9RdsilhqNsWsoZlah/7ke+ISHu4uHleD+U8R25kSmogCGV1Nh45IzWIaw qB4z0SHkN2a2l39xEcti8uWb3n3q+lacAQozBDDwZocTF6pOXKQ415nI9uL++z6Rlj8Y +O7qM18/TBJZw2DNknsc5E+X+eUCLM0+gVHhRQJ6aEd1nyzyBk70Q3602YbS9TYrsqzN +2Y8geNPeG8NaLe9NyJ9r/gmZSTXvwMqanfMIT6vXcT0PXtdbSX03pEA7l4wXAdRYedq D7Rw== X-Gm-Message-State: APf1xPC384mtey1iksC5MznMI0plVhyVIhx8GN3oZVFTvwTPhW6qw3eJ uzSloZT+vjW2Bg7G7E+rE3KbPzeeseWi9f+EzgY= X-Google-Smtp-Source: AH8x226uyWjVMdkuZec7lzlB4JGLuMcs12dr5TIfL/c1AZIDG3ca2L2qn7Zk3W0lM85CzI/PvldnAcFfv6pSTWmkxk4= X-Received: by 10.31.168.20 with SMTP id r20mr6075474vke.149.1518834813332; Fri, 16 Feb 2018 18:33:33 -0800 (PST) MIME-Version: 1.0 Sender: gmaxwell@gmail.com Received: by 10.103.136.69 with HTTP; Fri, 16 Feb 2018 18:33:32 -0800 (PST) In-Reply-To: <0213B102-7595-4177-A76C-FE4E8D7F0EDF@xbt.hk> References: <0213B102-7595-4177-A76C-FE4E8D7F0EDF@xbt.hk> From: Gregory Maxwell Date: Sat, 17 Feb 2018 02:33:32 +0000 X-Google-Sender-Auth: GfwKf8azv_ltcNoX2eoTQfE1QP8 Message-ID: To: Johnson Lau , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Alternative way to count sigops 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: Sat, 17 Feb 2018 02:33:35 -0000 On Fri, Feb 16, 2018 at 10:49 PM, Johnson Lau via bitcoin-dev wrote: > Since we have a block weight limit of 4,000,000 and sigop limit of 80,000, > each sigop could not use more than 50 weight unit on average. For new script > proposals we could count the actual number of sigop at execution (i.e. skip > unexecuted sigop, skip 0-size signature, count the actual checksig > operations in multi-sig), and make sure the number of executed sigop * 50 is > not greater than the size of the input. We have a related policy rule in Bitcoin Core for some time now, the weight of the transaction for the purpose of mining is max(weight,lambda*sigops), though we set lambda a bit lower than makes sense due to how checkmultisig. This policy rule replaced an earlier one which was almost equivalent to your proposal: it rejected transactions with too many sigops per the byte count, but we found it block actual more or less sensible transactions. Going forward I don't think this is a great framework. It works if the only expensive operations all involve large input data, but I think many proposals people have made for new operations would have computational cost which requires relatively small amounts of additional input-- aggregation is just one fairly minor example.