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
|
Return-Path: <rusty@ozlabs.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A00FEB43
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Sep 2019 11:01:29 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from ozlabs.org (ozlabs.org [203.11.71.1])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8FEA1C0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 27 Sep 2019 11:01:28 +0000 (UTC)
Received: by ozlabs.org (Postfix, from userid 1011)
id 46fpkt11yQz9sNx; Fri, 27 Sep 2019 21:01:26 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: Gleb Naumenko <naumenko.gs@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <8914e269-e922-43f4-8846-9fb21a8044f3@Spark>
References: <c06eeb3e-4611-4196-8d2f-f3c3470aeea3@Spark>
<8914e269-e922-43f4-8846-9fb21a8044f3@Spark>
Date: Fri, 27 Sep 2019 11:38:27 +0930
Message-ID: <87wodu7ap0.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, DATE_IN_PAST_06_12,
RCVD_IN_DNSWL_NONE 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] New BIP for p2p messages/state enabling
reconciliation-based protocols (Erlay)
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: Fri, 27 Sep 2019 11:01:29 -0000
Hi Gleb,
Minor feedback on reading the draft:
> sendrecon:
> uint32 version Must be exactly 1 currently.
At risk of quoting myself[1]: data doesn't have requirements. Actors do.
In this case, I assume you mean "writers must set this to 1". What do
readers do if it's not?
> reqreconcil
> uint8 q Coefficient used to estimate set difference.
You describe how to calculate q (as a floating point value), but not how
to encode it?
> Every node stores sets of 128-bit truncated IDs per every peer
"*a* set..." or is it "two sets" (if you include the snapshot?).
And " *for* every peer" (maybe "which supports tx reconciliation?")
> To the best of our knowledge, PinSketch is more bandwidth efficient
> than IBLT, especially for the small differences in sets we expect to
> operate over.
Remove "To the best of our knowledge, ": that makes it sound like it's
up for debate. I've implemented and experimented with IBLT, and it's
worse.
Cheers,
Rusty.
[1] https://github.com/lightningnetwork/lightning-rfc/blob/master/CONTRIBUTING.md#writing-the-requirements
|
