1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
Return-Path: <karljohan-alm@garage.co.jp>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 57154B0C
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 13 Sep 2017 08:27:59 +0900 (JST)
X-Received: by mail-it0-f72.google.com with SMTP id v140so12866285ita.3
for <bitcoin-dev@lists.linuxfoundation.org>;
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>
<DA22C531-2FAE-4332-B158-A3F96BF34002@xbt.hk>
<61D84B62-0F3F-48E1-B749-F628AD91BC12@friedenbach.org>
From: Karl Johan Alm <karljohan-alm@garage.co.jp>
Date: Wed, 13 Sep 2017 08:27:36 +0900
Message-ID: <CALJw2w49t5Wt1Czf4VTNj10opzPOS8ZDrRgoAwmeVFTeWWzBLg@mail.gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
<bitcoin-dev@lists.linuxfoundation.org> 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.
|
