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
123
124
125
126
127
128
129
130
131
132
133
134
135
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8480F284E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 Apr 2019 04:45:28 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 32FB479
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 20 Apr 2019 04:45:26 +0000 (UTC)
Date: Sat, 20 Apr 2019 04:45:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1555735524;
bh=/5BFRv73x1s3Mety7SM+/tVNH3L5RnLONcg7BX4w1I0=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=tTOKgSb7yHmpdPMjnXv+Ym5IJrK2mtk3Au0S+DLKEeJb9g+R5sSly7mA1kzyky856
aFQZMefM7tfmhODq7kbKCFPVf5Hf8IHQKARvRNBWysdHSxC6qW3XJP3lRq2sV44khH
iYoE4rAyh9uYEvZIFQjlB4lZsIcy7EuZonhQVnZw=
To: Ruben Somsen <rsomsen@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <IbAS3IZpoD0wJKQvVekHDjHJL0R97CSGKwyy3ScU5yl2NIDSqBsmUJqvU_M7b0MRRu2u9aQXaof0zTs1OC562vkYu8LzV7vSDM6Pj5j55yI=@protonmail.com>
In-Reply-To: <CAPv7TjbbYkXf62ApadMgOLef-Z9xTU1HQy_f+L3vNVUfRhChrw@mail.gmail.com>
References: <CAPv7TjYspkc1M=TKmBK8k0Zy857=bR7jSTarRDCr_5m2ktYHDQ@mail.gmail.com>
<xqVUmHu0RXeogboFL8ivsZywPQKEqLCsUZTV1NbsxNB4CYqrNqS8TpYsP8PJSowIGUeq8Nu1XPVd9N9Exg5Is11767ytI0Sq4lVp9MGdII4=@protonmail.com>
<CAEM=y+WVQz5x916sjCjWVmeEbRp4NoTyryxSH7uKNTHYz+Sdnw@mail.gmail.com>
<xNr214GpQ7_9duD4RV0j2nufLLMff4ipqPcZEAsDIsjLwWDan9UijTADW0iJ76pUuaXgYth_BHla-p6G3SOksaySbDZXKhQPLvIfLqo0JeA=@protonmail.com>
<CAEM=y+V0tMYBBLJhePfGUzyFNXVe9hr0F3QrX9JYFrDg5N1qXg@mail.gmail.com>
<SHsLdVIPZcn9yyZN9Hx3moQmWXY-2yC99tEsFllksV-66ZrJNMQfDr0qHK_rCZuBcEa8gIcnThkvgRDkU6BYQ_mxX7JxfI_uM6ndOF26ofk=@protonmail.com>
<CAPv7TjYeuCA1WDHgEpkN1K8=NM88fw43HJeP5TeRE7q0Q+Chzg@mail.gmail.com>
<EWP8Pzp8wS_Nh145H_g4w3yJaelXmm6UB12sa8MC2EsMbYFhm53C_kaOvjztksQpCNBBT0D0zuTbKHnEfEatlLKIa3whMlLZrihawZux1UY=@protonmail.com>
<CAPv7TjbbYkXf62ApadMgOLef-Z9xTU1HQy_f+L3vNVUfRhChrw@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sat, 20 Apr 2019 14:21:03 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving SPV security with PoW fraud proofs
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: Sat, 20 Apr 2019 04:45:28 -0000
Good morning Ruben,
> Hi ZmnSCPxj,
>
> > There is no safe way to use UTXO sets without identifying who is tellin=
g you those sets are valid, or making it expensive to lie
> > The first option requires trust and is weaker than SPV, the second requ=
ires committing to a proof-of-work
>
> Olaoluwa Osuntokun's BIP157 manages to function without a commitment:
> "If the client receives conflicting filter headers from different
> peers for any block and filter type, it SHOULD interrogate them to
> determine which is faulty."
>
> I am wondering if the same logic can be applied to UTXO sets or the
> fraud proofs I just described.
UTXO sets can only be validated by actually running the entire blockchain, =
i.e. fullnoding.
What BIP157 does is summarize data that is within a block, thus validating =
them can be done simply by downloading the block in question.
UTXO sets summarize data in the entire blockchain, hence proper validation =
requires downloading the entire blockchain.
Thus it cannot be a comparison point.
> > This makes no sense
> > or you trust that every peer you have is not omitting the proof.
>
> It's the latter, you trust every peer you have is not omitting the
> proof. It requires one honest peer. The reason this is acceptable is
> because you're already making that assumption. If none of your peers
> are honest, you have no guarantee of hearing about the chain with the
> most PoW.
But peers can be set up to allow you to hear of all chains while denying yo=
u proof of the invalidity of some UTXO.
This is precisely the "data unavailability claim" that shot down the previo=
us fraud proofs (i.e. absence of proof is not proof of absence, and proof o=
f UTXO validity was defined by proof of absence of any intervening spend of=
the UTXO).
Perhaps in combination with BIP157/158 it may be possible, if the filters c=
ontain UTXO spends and a BIP158 filter was committed to on-chain.
Then a proof of absence could be done by revealing all the BIP158 filters f=
rom the UTXO creation to the block being validated, as well as the blocks w=
hose BIP158 filters matched the UTXO and revealing that no, they actually d=
o not spend the UTXO.
--
Tangentially, we cannot just magically commit to anything on the blockchain=
.
Header blocks commit to block data and commit to some other header block.
All those header blocks and the block data need to be stored and transmitte=
d over the network somehow, even though they are "only" being committed to.
Thus, if you are adding new information to be committed, that may increase =
the resource usage of fullnodes.
So if UTXO set commitments, or utreexo commitments, or BIP158 filter digest=
s, etc. are committed to in the coinbase, they have to be stored somehow in=
fullnodes the entire UUTXO set, or the actual utreexo structure, or the ac=
tual BIP158 filter, etc. at each block.
Otherwise it would be pointless to store those commitments since it would n=
ot be possible to somehow acquire the data being committed to after-the-fac=
t.
This is probably still better than BIP37 but we should still be aware the a=
dditional load on fullnodes.
Regards,
ZmnSCPxj
|
