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
119
120
121
122
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 917E4982
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 01:32:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com
[209.85.220.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A766DA8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 01:32:17 +0000 (UTC)
Received: by qkbp125 with SMTP id p125so95677548qkb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 04 Jul 2015 18:32:17 -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:cc
:content-type; bh=545PjtTtrgZWyhJOxrFE3jNyb2K/Rd8qosXgYBMKuMs=;
b=hRQuwQOYpyIbCY8yR79KKV9Id8GeZa0w2aTGyIG7WmJjD99cwVSjAiEvZcuDkJd25b
DgqyFTg3y3lxr9o0sSV5wX+aTekvQ9NIuH8hc8sZHMJaK7fdWisIqu5HlF4RwuuCaxh5
JxIzZ3XeIHVqsw8SLod8GHVSytQCRVmI9O+2NreAvcm/NsI2CxJdnfPnXy5wnnqP3K3X
gLHA3PZklPHCfj2UfyHPUN/KPofoyBVm6nzSSHgGYNMWKriWqBVmIuDOwgZChi2YmhhF
6APo9ek05gxPatD5j5ZyCLsEnGQdDR0cdzlon+NOGsGhD9dIeiIdQPY23LVXQ1Qvs0RS
8ChQ==
MIME-Version: 1.0
X-Received: by 10.140.216.208 with SMTP id m199mr65684228qhb.69.1436059936858;
Sat, 04 Jul 2015 18:32:16 -0700 (PDT)
Received: by 10.140.93.162 with HTTP; Sat, 4 Jul 2015 18:32:16 -0700 (PDT)
In-Reply-To: <55986D44.20601@openbitcoinprivacyproject.org>
References: <COL402-EAS195B72E1CF2B75999C1AB11CD950@phx.gbl>
<20150704054453.GA348@savin.petertodd.org>
<5597F93B.3000205@openbitcoinprivacyproject.org>
<CAE-z3OWTzgYP7CKbFLf-YFKU+G6CNKND2DmAbnr_3_NjB-Y4fw@mail.gmail.com>
<55980361.9040707@openbitcoinprivacyproject.org>
<CAE-z3OXZDh=ww33Qr6yGxzm3rzquiP0LNo6yQzL1si+-dr3a_g@mail.gmail.com>
<55986D44.20601@openbitcoinprivacyproject.org>
Date: Sun, 5 Jul 2015 02:32:16 +0100
Message-ID: <CAE-z3OXX9wVCRiNHxpP3deTv63zOkJv4JDAYG8LXXOrFCoKVxg@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a1135d79669a52b051a16c256
X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,
RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Fork of invalid blocks due to BIP66 violations
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sun, 05 Jul 2015 01:32:21 -0000
--001a1135d79669a52b051a16c256
Content-Type: text/plain; charset=UTF-8
On Sun, Jul 5, 2015 at 12:33 AM, Justus Ranvier <
justus@openbitcoinprivacyproject.org> wrote:
> I think the problem is tractable if some reasonable assumptions are made
> about the ability of SPV clients to perform validity checks that don't
> involve any state outside a single transaction (or block):
>
> https://gist.github.com/justusranvier/451616fa4697b5f25f60
>
>
I agree, it is definitely tractable.
If Bitcoin was being designed from scratch, it could be made even easier.
As things stand, the extra commitment information needs to be added to
extra trees, which themselves need to be checked.
The "prover", in your example, should ideally store additional meta-data
along with each block.
If P2SH was made mandatory, then much of the transaction validation could
be performed on the transaction alone.
Both the signature and the public key would be included in the spending
transaction.
--001a1135d79669a52b051a16c256
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Jul 5, 2015 at 12:33 AM, Justus Ranvier <span dir=3D"ltr"><<a href=
=3D"mailto:justus@openbitcoinprivacyproject.org" target=3D"_blank">justus@o=
penbitcoinprivacyproject.org</a>></span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><span class=3D"">
</span>I think the problem is tractable if some reasonable assumptions are =
made<br>
about the ability of SPV clients to perform validity checks that don't<=
br>
involve any state outside a single transaction (or block):<br>
<br>
<a href=3D"https://gist.github.com/justusranvier/451616fa4697b5f25f60" rel=
=3D"noreferrer" target=3D"_blank">https://gist.github.com/justusranvier/451=
616fa4697b5f25f60</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div><=
br></div><div>I agree, it is definitely tractable.<br><br></div><div>If Bit=
coin was being designed from scratch, it could be made even easier.<br><br>=
</div><div>As things stand, the extra commitment information needs to be ad=
ded to extra trees, which themselves need to be checked.<br></div><div><br>=
</div><div>The "prover", in your example, should ideally store ad=
ditional meta-data along with each block.<br><br></div><div>If P2SH was mad=
e mandatory, then much of the transaction validation could be performed on =
the transaction alone.<br><br></div><div>Both the signature and the public =
key would be included in the spending transaction.<br></div></div></div></d=
iv>
--001a1135d79669a52b051a16c256--
|
