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 57154B0C for ; Tue, 12 Sep 2017 23:35:57 +0000 (UTC) X-Greylist: delayed 00:07:49 by SQLgrey-1.7.6 Received: from mo.garage.hdemail.jp (mo.garage.hdemail.jp [46.51.242.127]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C152AE5 for ; Tue, 12 Sep 2017 23:35:56 +0000 (UTC) Received: from ip-10-217-1-36.ap-northeast-1.compute.internal (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-mf-postfix) with SMTP id 2953614C0C5 for ; Wed, 13 Sep 2017 08:28:06 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Received: from unknown (HELO mo.garage.hdemail.jp) (127.0.0.1) by 0 with SMTP; 13 Sep 2017 08:28:03 +0900 X-Received: from mo.garage.hdemail.jp (localhost.localdomain [127.0.0.1]) by mo.garage.hdemail.jp (hde-ma-postfix) with ESMTP id AB2784C071 for ; Wed, 13 Sep 2017 08:28:03 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) Received: from gw29.oz.hdemail.jp (ip-10-174-11-156.ap-northeast-1.compute.internal [10.174.11.156]) by mo.garage.hdemail.jp (hde-mf-postfix) with ESMTP id 7F2B214C0C5 for ; Wed, 13 Sep 2017 08:28:03 +0900 (JST) (envelope-from karljohan-alm@garage.co.jp) X-Durian-MailFrom: karljohan-alm@garage.co.jp X-Durian-RcptTo: bitcoin-dev@lists.linuxfoundation.org Received: from gw29.oz.hdemail.jp (gw29.oz.hdemail.jp [127.0.0.1]) by gw29.oz.hdemail.jp (gw29.oz.hdemail.jp [127.0.0.1]); Wed, 13 Sep 2017 08:28:00 +0900 X-Received: from mail-it0-f72.google.com (lb1.oz.lo.hdemail.jp [54.248.222.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw29.oz.hdemail.jp (Postfix) with ESMTP id AFE9B148C0E7 for ; Wed, 13 Sep 2017 08:27:59 +0900 (JST) X-Received: by mail-it0-f72.google.com with SMTP id v140so12866285ita.3 for ; Tue, 12 Sep 2017 16:27:59 -0700 (PDT) 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=qd9Gmw5b5a6f1nV3db2pacJczXv6R4PpbHLWG/IPh5Q=; b=LU3lxRMG3Mu5iKBhRXUgNQ+Gt9PPYIilLNI8+Z7d/YmUOVu9+gSJGu/ONK8mfV2d+5 st2foqtCFP0PJ5pkdrY0ooiahT4mcmCyh2ZT2N63lsk6Yb2NQkUyKt8HHsSgnve/ZsWG EcJsCI312uG9plwOP1rY4sNTNrGj8N+tzq/fSCHtNUtruAYLzADEJkP3BZGX4zriTf5v YLNzlHbg3Uon6p6Dl9dg4BRze7Rgv01dIOhoQ/Zz3p5NeYfrfD3XiHY65so2Kwnmyv0V 5EUrg29Vflpc6g/+gFhkk1jpVhy6+elPs+o4T+Wg2gS5dj+RQh4EfXR4BL6secLWMVrB LtSA== X-Gm-Message-State: AHPjjUhJuO+d52nxMPhY4foKoZ46PaTcIbR+czqwuyPSBKQo0Gg28jy6 JAmd7iFvrmzlvazVxYkHIC5vrmqh3ZFnsKot6rjLnzTzWPXLTenld4sNQpLmTyJl+ZW9lHY4mQ2 PwqnXP+eFSV/p0aN5I+viXNd1Y4wqlybAgvNSLkiH0U4kow== X-Received: by 10.107.17.103 with SMTP id z100mr23968983ioi.9.1505258877736; Tue, 12 Sep 2017 16:27:57 -0700 (PDT) X-Google-Smtp-Source: AOwi7QBlfnsE5/JgWX77uE23aqdo+K4XwnDcLA1rUDifV27u6bKJgG+tg8jHqpGjrANneHdaXJXLw8H1Kyrk3HCbbH0= X-Received: by 10.107.17.103 with SMTP id z100mr23968971ioi.9.1505258877428; Tue, 12 Sep 2017 16:27:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.2.151.172 with HTTP; Tue, 12 Sep 2017 16:27:36 -0700 (PDT) In-Reply-To: <61D84B62-0F3F-48E1-B749-F628AD91BC12@friedenbach.org> References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org> <26AD157C-A5A9-48C3-8D29-0AD1ED35EDDD@xbt.hk> <2419914E-E196-44B4-8663-599AF616A897@friedenbach.org> <61D84B62-0F3F-48E1-B749-F628AD91BC12@friedenbach.org> From: Karl Johan Alm Date: Wed, 13 Sep 2017 08:27:36 +0900 Message-ID: To: Mark Friedenbach , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 13 Sep 2017 08:12:48 +0000 Subject: Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST 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: Tue, 12 Sep 2017 23:35:57 -0000 On Wed, Sep 13, 2017 at 4:57 AM, Mark Friedenbach via bitcoin-dev wrote: >> Without the limit I think we would be DoS-ed to dead > > 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. Sidenote-ish, but I also believe it would be fairly trivial to keep a per UTXO tally and demand additional fees when trying to respend a UTXO which was previously "spent" with an invalid op count. I.e. if you sign off on an input for a tx that you know is bad, the UTXO in question will be penalized proportionately to the wasted ops when included in another transaction later. That would probably kill that DoS attack as the attacker would effectively lose bitcoin every time, even if it was postponed until they spent the UTXO. The only thing clients would need to do is to add a fee rate penalty ivar and a mapping of outpoint to penalty value, probably stored as a separate .dat file. I think.