summaryrefslogtreecommitdiff
path: root/f8/30fdb91c4af410316964a57428d48e0c21296d
blob: 82a91430629ae62221234fd0d48beeb9fdb0f288 (plain)
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
Return-Path: <dave@dtrt.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id F1774C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 27 Feb 2021 19:20:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id CBA134F0DB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 27 Feb 2021 19:20:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 2.299
X-Spam-Level: **
X-Spam-Status: No, score=2.299 tagged_above=-999 required=5
 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
 DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_DBL_SPAM=2.5]
 autolearn=no autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=dtrt.org
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id NdlhDl1CiI2Q
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 27 Feb 2021 19:20:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from newmail.dtrt.org (newmail.dtrt.org [45.79.129.87])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 68DFC4F0D3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 27 Feb 2021 19:20:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dtrt.org;
 s=20201208; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:
 Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=r9d2WNO2JQ1giGWnvZt9IVzwGCgDGeOMVVg6qGDcSxQ=; b=coGdsyEW63L20+vGnxQpkVLG3f
 4+DAKwZ72inUhPahZaeU4OgCirNoDnIYdusngP74Wdz6dy7vl+nipaDqiJxW6TQawBbfiQ8qxvHjF
 ylEGpkM0zzmdgdqU9mV74HqWxT8PTVldDmvPjEpfXoRHxyN2lSTDOhv9nPsf+sN+E2QI=;
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
 (envelope-from <dave@dtrt.org>)
 id 1lG58h-00006h-91; Sat, 27 Feb 2021 09:20:31 -1000
Date: Sat, 27 Feb 2021 09:19:34 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Keagan McClelland <keagan.mcclelland@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20210227191934.phk4z6k2chaefxwt@ganymede>
References: <CALeFGL1WSSA69ARvJW3di-UC_gz7NV9q7=6zd7s=CHnmttdQFg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="dmbiwa3u2dvgu5er"
Content-Disposition: inline
In-Reply-To: <CALeFGL1WSSA69ARvJW3di-UC_gz7NV9q7=6zd7s=CHnmttdQFg@mail.gmail.com>
User-Agent: NeoMutt/20180716
Subject: Re: [bitcoin-dev] A design for Probabilistic Partial Pruning
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 27 Feb 2021 19:20:35 -0000


--dmbiwa3u2dvgu5er
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Feb 26, 2021 at 11:40:35AM -0700, Keagan McClelland via bitcoin-dev=
 wrote:
> Hi all,

Hi Keagan,

> 4. Once the node's IBD is complete it would advertise this as a peer
> service, advertising its seed and threshold, so that nodes could
> deterministically deduce which of its peers had which blocks.

Although some of the details differed, I believe this general idea of
sharded block storage was previously discussed in the context of BIP159,
which warns:

    "Peers may have different prune depths (depending on the peers
    configuration, disk space, etc.) which can result in a
    fingerprinting weakness (finding the prune depth through getdata
    requests). NODE_NETWORK_LIMITED supporting peers SHOULD avoid
    leaking the prune depth and therefore not serve blocks deeper than
    the signaled NODE_NETWORK_LIMITED threshold (288 blocks)."

- BIP: https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki#count=
er-measures-for-peer-fingerprinting
- Discussion thread 1: https://lists.linuxfoundation.org/pipermail/bitcoin-=
dev/2017-April/014186.html
- Discussion thread 2: https://lists.linuxfoundation.org/pipermail/bitcoin-=
dev/2017-May/014314.html
- Discussion thread 2, continued: https://lists.linuxfoundation.org/piperma=
il/bitcoin-dev/2017-April/014186.html
- BIP159-related PR, review comments: https://github.com/bitcoin/bitcoin/pu=
ll/10387

> If you have thoughts on
>=20
> A. The protocol design itself
> B. The barriers to put this kind of functionality into Core
>=20
> I would love to hear from you,

I think it would be unlikely for any popular node software to adopt a
technique that could make specific nodes easily fingerprintable on an
ongoing basis unless it solved some other urgent problem.  Luke Dashjr's
rough data collection currently shows 5,629 archival listening nodes,[1]
which is a substantial fraction of the roughly 10,000 listening nodes
reported by Addy Yeow,[2] so I don't think we're near the point of
needing to worry about the unavailability of historic blocks.

    [1] https://luke.dashjr.org/programs/bitcoin/files/charts/services.html
    [2] https://bitnodes.io/dashboard/

However, if there's a reasonable solution to the fingerprinting problem,
I do think node developers would find that very interesting.

-Dave

--dmbiwa3u2dvgu5er
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmA6m0YACgkQ2dtBqWwi
adMHNRAAsUgMWNimFvcTX+8kqT9htSnQ9GG/4Ie9T/MpDuNBAOcWKwFM2K3xZ4v4
BLmT8z3kUx2OrJidMxpSk52ODeqIRmExlXs0Tazq9Mae2/xrw4/y2UEtsy6+R77U
35OWQ5EaSecV7PDFQa8rqwyAyeADuIWlr+Vyt9RlFxe2FgWv15WXx5KZ73r140lH
aY2L5xQnQ2s5AnhMd6NcaU3QICU/bNkORKmgTyGby84QcLVBWEw6Lq2DuzYP2DsB
aafs2p40+cF/XGznAJxDBF0Nw5Iq475sHJ1r8oyGCdFCsbP7K+PYQ5aWqucPnIy8
jmL97VyBpvOxAG9ITBWnESuUnHTjbNrkARTe+CCseryf4VIvPlVKhstWpYo/ai+T
LlZaEIMkc4/tEuhSnZ9tmH4vwXeJPMt95+YWdpXXb6+MBtMFioeIXZj+aSrT3TPN
g5A8c9cRmQvRcMmxRyd3Z6PF/m4y7FUwf1psprlorE+TXKCXUXneyseISTce+iZ3
uRH8Ltyv2kntzrfqRx9XcVbFdOjxHpdu/wUFxS4UgNZ6+x+KxQdC+1KwQsK6ysM5
1dUfjSDzO1onowElvDc4PbPj7Z9BGvmy/jcjA6/L37wvV8WHmNw7Hd65NxDthiVC
3FHnOY5TS7B4lii2cDUaAy875NP3X2wrL0SOf8gGaKeTDeA7v9U=
=aU5j
-----END PGP SIGNATURE-----

--dmbiwa3u2dvgu5er--