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
Precedence: list


--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--