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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
Return-Path: <tomz@freedommail.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 7E239282
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 May 2016 11:33:09 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx-out03.mykolab.com (mx01.mykolab.com [95.128.36.1])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5E29E1A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 9 May 2016 11:33:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at kolabnow.com
X-Spam-Score: -2.9
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
Received: from mx03.mykolab.com (mx03.mykolab.com [10.20.7.101])
by mx-out03.mykolab.com (Postfix) with ESMTPS id D80DE20202;
Mon, 9 May 2016 13:33:01 +0200 (CEST)
From: Tom <tomz@freedommail.ch>
To: Gregory Maxwell <greg@xiph.org>
Date: Mon, 09 May 2016 12:32:59 +0100
Message-ID: <2273040.Bd6rtJjYLF@garp>
In-Reply-To: <CAAS2fgRiSNNHA5psaUYOM6rHfjJ1aOgWhnsT8Z-pU4FBcR_65w@mail.gmail.com>
References: <5727D102.1020807@mattcorallo.com> <86058327.pdmfHP132A@kiwi>
<CAAS2fgRiSNNHA5psaUYOM6rHfjJ1aOgWhnsT8Z-pU4FBcR_65w@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 09 May 2016 12:16:58 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Compact Block Relay BIP
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: Mon, 09 May 2016 11:33:09 -0000
On Monday 09 May 2016 10:43:02 Gregory Maxwell wrote:
> On Mon, May 9, 2016 at 9:35 AM, Tom Zander via bitcoin-dev
>
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > You misunderstand the networking effects.
> > The fact that your node is required to choose which one to set the
> > announce
> > bit on implies that it needs to predict which node will have the best data
> > in the future.
>
> Not required. It may.
It is required, in the reference of wanting to actually use compact block
relay.
> Testing on actual nodes in the actual network (not a "lab") shows
Apologies, I thought that the term was wider known. "Laboratory situations"
is used where I am from as the opposite of real-world messy and unpredictable
situations.
So, your measurements may be true, but are not useful to decide how well it
behaves under less optimal situations. aka "the real world".
> This also _increases_ robustness. Right now a single peer failing at
> the wrong time will delay blocks with a long time out.
If your peers that were supposed to send you a compact block fail, then you'll
end up in exactly that same situation again. Only with various timeouts in
between before you get your block making it a magnitude slower.
In networking this is solved by reacting instead of predicting. The network is
not stable. Your protocol design assumes it to be.
> > Another problem with your solution is that nodes send a much larger amount
> > of unsolicited data to peers in the form of the thin-block compared to
> > the normal inv or header-first data.
>
> "High bandwidth" mode
Another place where I may have explained better.
This is not about the difference about the two modes of your design.
This is about the design as a whole. As compared to current.
> > Am I to understand that you choose the solution based on the fact that
> > service bits are too expensive to extend? (if not, please respond to my
> > previous question actually answering the suggestion)
> >
> > That sounds like a rather bad way of doing design. Maybe you can add a
> > second service bits field of message instead and then do the compact
> > blocks correctly.
> Service bits are not generally a good mechanism for negating optional
> peer-local parameters.
Service bits are exactly the right solution to indicate additional p2p
feature-support.
> [It's a little disconcerting that you appear to be maintaining a fork
> and are unaware of this.]
ehm...
> > Wait, you didn't steal the variable length encoding from an existing
> > standard and you programmed a new one?
>
> This is one of the two variable length encodings used for years in
> Bitcoin Core. This is just the first time it's shown up in a BIP.
>
> > Look at UTF-8 on wikipedia, you may have "invented" the same encoding that
> > IBM published in 1992.
>
> The similarity with UTF-8 is that both are variable length and some
> control information is in the high bits. The similarity ends there.
That's all fine and well, it doesn't at any point take away from my point that
any specification should NOT invent something new that has for decades had a
great specification already.
If you make a spec to be used by all nodes, on the wire, don't base it on your
proprietary implementation. Please.
> > Just the first (highest) 8 bytes of a sha256 hash.
> >
> > The amount of collisions will not be less if you start xoring the rest.
> > The whole reason for doing this extra work is also irrelevant as a spam
> > protection.
>
> Then you expose it to a trivial collision attack: To find two 64 bit
> hashes that collide I need perform only roughly 2^32 computation. Then
> I can send them to the network.
No, you still need to have done a POW.
Next to that, your scheme is 2^32 computations *and* some XORs. The XORs are
percentage wise a rounding error on the total time. So your argument also
destroys your own addition.
> This issue is eliminated by salting the hash.
The issue is better eliminated by not allowing nodes to send uninvited large
messages.
I don't think we're getting anywhere.
I'm not sold on your design and I explained why. I tried explaining in this
email some misconceptions that may have appeared after my initial emails. I
hope things are more clear.
|
