path: root/c8/315f3385d4b010e0cd83954a72caa0f9d9cdd1

Return-Path: <laolu32@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 16644259
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  1 Jun 2017 22:10:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com
	[209.85.161.172])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D9CA212A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  1 Jun 2017 22:10:46 +0000 (UTC)
Received: by mail-yw0-f172.google.com with SMTP id l74so26220649ywe.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 01 Jun 2017 15:10:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=YBzxMGD4lc+uH6ZSuRNijT0/46nh78ylOu4DM+yMLNM=;
	b=TKa1E4Gsu0bDPEY1JW6iCuLuwgoR1tf4CxvW41sHR/X5iNrOBvRtCHWeoA+BcqER4A
	sf5LLOq4h8X/I2r4rkOA0TxwqjtziwGg0+HZV7X2GQl2Q1++v/BGajOXRhks8JDZx9Kv
	tNvk5oEG20JAIPhEu9JiPW+wQOT9RyFQexRa5OM47jX9ECtNJJL72TYDHnsY+gvDlTzg
	7DHanLPeL/9I+Hp6B8o72YfocrPV4EfPSTwD4HRRJW8/AfpsukFwJhzujHEUqFP7yUna
	Xg1efCFI6rpKDDZNbhx/6bEW7gpj/YOz59MKrpxbPPXoOdj3mT7qz5jGlfTYdPKTjlWk
	ScSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=YBzxMGD4lc+uH6ZSuRNijT0/46nh78ylOu4DM+yMLNM=;
	b=suTs49zZQT2ZunnzyXD41Q2ExdFWfmL7JO+DbM96+pJeoIDqH2pVqRBHgQw26rh3Pq
	wJBRIasmKxRDqPsKRLdQE9YFdZUuSvl7rxV7og5v4YXeoHSdNspKGKCui9C2RmyGY4dA
	L9V5F0n/JPe3a5jUKhYjL1bStc7BpCZ961NwD2VQ4FMsCwqYLVY5+za9XqDo0t1XytZT
	5OuE4o4W0rPxXC3Lyce5nksj38sM/9FVIuywzqmzEhMItQYtpNEWieklxGhZuvEA63Ue
	AoXL3s2MBuE4xLw/lg7Db+/g1EETUkk1KrzzmquepWd1SMJu9EPatVN8P7/DCgTGTbPa
	4m4w==
X-Gm-Message-State: AODbwcDujnl6YQRq36D2e4gUX6+/4aCQdXHNThs+ZDL2t6OBKj1jCrVU
	JvoT8kiCXIqZuf51PXnNvXONyXTQ6KPZ
X-Received: by 10.129.166.8 with SMTP id d8mr3567863ywh.324.1496355045982;
	Thu, 01 Jun 2017 15:10:45 -0700 (PDT)
MIME-Version: 1.0
References: <CAO3Pvs8ccTkgrecJG6KFbBW+9moHF-FTU+4qNfayeE3hM9uRrg@mail.gmail.com>
	<B445007A-9FA3-4B1D-8CD0-F0371602DC5F@mattcorallo.com>
In-Reply-To: <B445007A-9FA3-4B1D-8CD0-F0371602DC5F@mattcorallo.com>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Thu, 01 Jun 2017 22:10:34 +0000
Message-ID: <CAO3Pvs-q89HDb9a9xtYMBm8RNtaQH1d+5B6S1YPk3C0JWM+vzA@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>, 
	Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev
	<bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="94eb2c12992af95ec60550ed4efb"
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM 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] BIP Proposal: Compact Client Side Filtering for
 Light Clients
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: Thu, 01 Jun 2017 22:10:48 -0000

--94eb2c12992af95ec60550ed4efb
Content-Type: text/plain; charset="UTF-8"

Eric wrote:
> Thanks for sending this proposal! I look forward to having a great
> discussion around this.

Thanks Eric! We really appreciated the early feedback you gave on the
initial design.

One aspect which isn't in this BIP draft is direct support for unconfirmed
transactions. I consider such a feature an important UX feature for mobile
phones, and something which I've personally seen as an important
UX-experience when on-boarding new users to Bitcoin. This was brought up
in the original "bfd" mailing list chain [1]. Possible solutions are: a
new beefier INV message which contains enough information to be able to
identify relevant outputs created in a transaction, or a "streaming" p2p
extension that allows light clients to receive notifications of mempool
inclusion based on only (pkScript, amount) pairs.

Matt wrote:
> looks like you have no way to match the input prevouts being spent, which
> is rather nice from a "watch for this output being spent" pov.

Perhaps we didn't make this clear enough, but it _is_ indeed possible to
watch an output for spentness. Or maybe you mean matching on the
_script_ being spent?

From the BIP draft:
> for each transaction, normal filters contain:
>  * The outpoints of each input within a transaction.
>  ...

Within the integration for lnd, we specifically use this feature to be
able to watch for when channels have been closed within the network graph,
or channels _directly_ under our control have been spent (either
unilateral channel closure, or a revocation beach).

-- Laolu

[1]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013397.html


On Thu, Jun 1, 2017 at 2:33 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> Quick comment before I finish reading it completely, looks like you have
> no way to match the input prevouts being spent, which is rather nice from a
> "watch for this output being spent" pov.
>
> On June 1, 2017 3:01:14 PM EDT, Olaoluwa Osuntokun via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >Hi y'all,
> >
> >Alex Akselrod and I would like to propose a new light client BIP for
> >consideration:
> >*
> >https://github.com/Roasbeef/bips/blob/master/gcs_light_client.mediawiki
> >
> >This BIP proposal describes a concrete specification (along with a
> >reference implementations[1][2][3]) for the much discussed client-side
> >filtering reversal of BIP-37. The precise details are described in the
> >BIP, but as a summary: we've implemented a new light-client mode that
> >uses
> >client-side filtering based off of Golomb-Rice coded sets. Full-nodes
> >maintain an additional index of the chain, and serve this compact
> >filter
> >(the index) to light clients which request them. Light clients then
> >fetch
> >these filters, query the locally and _maybe_ fetch the block if a
> >relevant
> >item matches. The cool part is that blocks can be fetched from _any_
> >source, once the light client deems it necessary. Our primary
> >motivation
> >for this work was enabling a light client mode for lnd[4] in order to
> >support a more light-weight back end paving the way for the usage of
> >Lightning on mobile phones and other devices. We've integrated neutrino
> >as a back end for lnd, and will be making the updated code public very
> >soon.
> >
> >One specific area we'd like feedback on is the parameter selection.
> >Unlike
> >BIP-37 which allows clients to dynamically tune their false positive
> >rate,
> >our proposal uses a _fixed_ false-positive. Within the document, it's
> >currently specified as P = 1/2^20. We've done a bit of analysis and
> >optimization attempting to optimize the following sum:
> >filter_download_bandwidth + expected_block_false_positive_bandwidth.
> >Alex
> >has made a JS calculator that allows y'all to explore the affect of
> >tweaking the false positive rate in addition to the following
> >variables:
> >the number of items the wallet is scanning for, the size of the blocks,
> >number of blocks fetched, and the size of the filters themselves. The
> >calculator calculates the expected bandwidth utilization using the CDF
> >of
> >the Geometric Distribution. The calculator can be found here:
> >https://aakselrod.github.io/gcs_calc.html. Alex also has an empirical
> >script he's been running on actual data, and the results seem to match
> >up
> >rather nicely.
> >
> >We we're excited to see that Karl Johan Alm (kallewoof) has done some
> >(rather extensive!) analysis of his own, focusing on a distinct
> >encoding
> >type [5]. I haven't had the time yet to dig into his report yet, but I
> >think I've read enough to extract the key difference in our encodings:
> >his
> >filters use a binomial encoding _directly_ on the filter contents, will
> >we
> >instead create a Golomb-Coded set with the contents being _hashes_ (we
> >use
> >siphash) of the filter items.
> >
> >Using a fixed fp=20, I have some stats detailing the total index size,
> >as
> >well as averages for both mainnet and testnet. For mainnet, using the
> >filter contents as currently described in the BIP (basic + extended),
> >the
> >total size of the index comes out to 6.9GB. The break down is as
> >follows:
> >
> >    * total size:  6976047156
> >    * total avg:  14997.220622758816
> >    * total median:  3801
> >    * total max:  79155
> >    * regular size:  3117183743
> >    * regular avg:  6701.372750217131
> >    * regular median:  1734
> >    * regular max:  67533
> >    * extended size:  3858863413 <(385)%20886-3413>
> >    * extended avg:  8295.847872541684
> >    * extended median:  2041
> >    * extended max:  52508
> >
> >In order to consider the average+median filter sizes in a world worth
> >larger blocks, I also ran the index for testnet:
> >
> >    * total size:  2753238530
> >    * total avg:  5918.95736054141
> >    * total median:  60202
> >    * total max:  74983
> >    * regular size:  1165148878
> >    * regular avg:  2504.856172982827
> >    * regular median:  24812
> >    * regular max:  64554
> >    * extended size:  1588089652
> >    * extended avg:  3414.1011875585823
> >    * extended median:  35260
> >    * extended max:  41731
> >
> >Finally, here are the testnet stats which take into account the
> >increase
> >in the maximum filter size due to segwit's block-size increase. The max
> >filter sizes are a bit larger due to some of the habitual blocks I
> >created last year when testing segwit (transactions with 30k inputs,
> >30k
> >outputs, etc).
> >
> >     * total size:  585087597
> >     * total avg:  520.8839608674402
> >     * total median:  20
> >     * total max:  164598
> >     * regular size:  299325029
> >     * regular avg:  266.4790836307566
> >     * regular median:  13
> >     * regular max:  164583
> >     * extended size:  285762568
> >     * extended avg:  254.4048772366836
> >     * extended median:  7
> >     * extended max:  127631
> >
> >For those that are interested in the raw data, I've uploaded a CSV file
> >of raw data for each block (mainnet + testnet), which can be found
> >here:
> >     * mainnet: (14MB):
> >https://www.dropbox.com/s/4yk2u8dj06njbuv/mainnet-gcs-stats.csv?dl=0
> >     * testnet: (25MB):
> >https://www.dropbox.com/s/w7dmmcbocnmjfbo/gcs-stats-testnet.csv?dl=0
> >
> >
> >We look forward to getting feedback from all of y'all!
> >
> >-- Laolu
> >
> >
> >[1]: https://github.com/lightninglabs/neutrino
> >[2]: https://github.com/Roasbeef/btcd/tree/segwit-cbf
> >[3]: https://github.com/Roasbeef/btcutil/tree/gcs/gcs
> >[4]: https://github.com/lightningnetwork/lnd/
> >
> >-- Laolu
>

--94eb2c12992af95ec60550ed4efb
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Eric wrote:</div><div>&gt; Thanks for sending this pr=
oposal! I look forward to having a great</div><div>&gt; discussion around t=
his.</div><div><br></div><div>Thanks Eric! We really appreciated the early =
feedback you gave on the</div><div>initial design.</div><div><br></div><div=
>One aspect which isn&#39;t in this BIP draft is direct support for unconfi=
rmed</div><div>transactions. I consider such a feature an important UX feat=
ure for mobile</div><div>phones, and something which I&#39;ve personally se=
en as an important</div><div>UX-experience when on-boarding new users to Bi=
tcoin. This was brought up</div><div>in the original &quot;bfd&quot; mailin=
g list chain [1]. Possible solutions are: a</div><div>new beefier INV messa=
ge which contains enough information to be able to</div><div>identify relev=
ant outputs created in a transaction, or a &quot;streaming&quot; p2p</div><=
div>extension that allows light clients to receive notifications of mempool=
</div><div>inclusion based on only (pkScript, amount) pairs.</div><div><br>=
</div><div>Matt wrote:</div><div>&gt; looks like you have no way to match t=
he input prevouts being spent, which</div><div>&gt; is rather nice from a &=
quot;watch for this output being spent&quot; pov.=C2=A0</div><div><br></div=
><div>Perhaps we didn&#39;t make this clear enough, but it _is_ indeed poss=
ible to</div><div>watch an output for spentness. Or maybe you mean matching=
 on the=C2=A0</div><div>_script_ being spent?</div><div><br></div><div>From=
 the BIP draft:</div><div>&gt; for each transaction, normal filters contain=
:</div><div>&gt; =C2=A0* The outpoints of each input within a transaction.<=
/div><div>&gt; =C2=A0...</div><div><br></div><div>Within the integration fo=
r lnd, we specifically use this feature to be</div><div>able to watch for w=
hen channels have been closed within the network graph,</div><div>or channe=
ls _directly_ under our control have been spent (either</div><div>unilatera=
l channel closure, or a revocation beach).</div><div><br></div><div>-- Laol=
u</div><div><br></div><div>[1]: <a href=3D"https://lists.linuxfoundation.or=
g/pipermail/bitcoin-dev/2017-January/013397.html">https://lists.linuxfounda=
tion.org/pipermail/bitcoin-dev/2017-January/013397.html</a></div><div><br><=
/div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Jun 1, 2=
017 at 2:33 PM Matt Corallo &lt;<a href=3D"mailto:lf-lists@mattcorallo.com"=
>lf-lists@mattcorallo.com</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">Quick comment before I finish reading it completely, looks like you h=
ave no way to match the input prevouts being spent, which is rather nice fr=
om a &quot;watch for this output being spent&quot; pov.<br>
<br>
On June 1, 2017 3:01:14 PM EDT, Olaoluwa Osuntokun via bitcoin-dev &lt;<a h=
ref=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitc=
oin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;Hi y&#39;all,<br>
&gt;<br>
&gt;Alex Akselrod and I would like to propose a new light client BIP for<br=
>
&gt;consideration:<br>
&gt;*<br>
&gt;<a href=3D"https://github.com/Roasbeef/bips/blob/master/gcs_light_clien=
t.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/Roasbe=
ef/bips/blob/master/gcs_light_client.mediawiki</a><br>
&gt;<br>
&gt;This BIP proposal describes a concrete specification (along with a<br>
&gt;reference implementations[1][2][3]) for the much discussed client-side<=
br>
&gt;filtering reversal of BIP-37. The precise details are described in the<=
br>
&gt;BIP, but as a summary: we&#39;ve implemented a new light-client mode th=
at<br>
&gt;uses<br>
&gt;client-side filtering based off of Golomb-Rice coded sets. Full-nodes<b=
r>
&gt;maintain an additional index of the chain, and serve this compact<br>
&gt;filter<br>
&gt;(the index) to light clients which request them. Light clients then<br>
&gt;fetch<br>
&gt;these filters, query the locally and _maybe_ fetch the block if a<br>
&gt;relevant<br>
&gt;item matches. The cool part is that blocks can be fetched from _any_<br=
>
&gt;source, once the light client deems it necessary. Our primary<br>
&gt;motivation<br>
&gt;for this work was enabling a light client mode for lnd[4] in order to<b=
r>
&gt;support a more light-weight back end paving the way for the usage of<br=
>
&gt;Lightning on mobile phones and other devices. We&#39;ve integrated neut=
rino<br>
&gt;as a back end for lnd, and will be making the updated code public very<=
br>
&gt;soon.<br>
&gt;<br>
&gt;One specific area we&#39;d like feedback on is the parameter selection.=
<br>
&gt;Unlike<br>
&gt;BIP-37 which allows clients to dynamically tune their false positive<br=
>
&gt;rate,<br>
&gt;our proposal uses a _fixed_ false-positive. Within the document, it&#39=
;s<br>
&gt;currently specified as P =3D 1/2^20. We&#39;ve done a bit of analysis a=
nd<br>
&gt;optimization attempting to optimize the following sum:<br>
&gt;filter_download_bandwidth + expected_block_false_positive_bandwidth.<br=
>
&gt;Alex<br>
&gt;has made a JS calculator that allows y&#39;all to explore the affect of=
<br>
&gt;tweaking the false positive rate in addition to the following<br>
&gt;variables:<br>
&gt;the number of items the wallet is scanning for, the size of the blocks,=
<br>
&gt;number of blocks fetched, and the size of the filters themselves. The<b=
r>
&gt;calculator calculates the expected bandwidth utilization using the CDF<=
br>
&gt;of<br>
&gt;the Geometric Distribution. The calculator can be found here:<br>
&gt;<a href=3D"https://aakselrod.github.io/gcs_calc.html" rel=3D"noreferrer=
" target=3D"_blank">https://aakselrod.github.io/gcs_calc.html</a>. Alex als=
o has an empirical<br>
&gt;script he&#39;s been running on actual data, and the results seem to ma=
tch<br>
&gt;up<br>
&gt;rather nicely.<br>
&gt;<br>
&gt;We we&#39;re excited to see that Karl Johan Alm (kallewoof) has done so=
me<br>
&gt;(rather extensive!) analysis of his own, focusing on a distinct<br>
&gt;encoding<br>
&gt;type [5]. I haven&#39;t had the time yet to dig into his report yet, bu=
t I<br>
&gt;think I&#39;ve read enough to extract the key difference in our encodin=
gs:<br>
&gt;his<br>
&gt;filters use a binomial encoding _directly_ on the filter contents, will=
<br>
&gt;we<br>
&gt;instead create a Golomb-Coded set with the contents being _hashes_ (we<=
br>
&gt;use<br>
&gt;siphash) of the filter items.<br>
&gt;<br>
&gt;Using a fixed fp=3D20, I have some stats detailing the total index size=
,<br>
&gt;as<br>
&gt;well as averages for both mainnet and testnet. For mainnet, using the<b=
r>
&gt;filter contents as currently described in the BIP (basic + extended),<b=
r>
&gt;the<br>
&gt;total size of the index comes out to 6.9GB. The break down is as<br>
&gt;follows:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 * total size:=C2=A0 6976047156<br>
&gt;=C2=A0 =C2=A0 * total avg:=C2=A0 14997.220622758816<br>
&gt;=C2=A0 =C2=A0 * total median:=C2=A0 3801<br>
&gt;=C2=A0 =C2=A0 * total max:=C2=A0 79155<br>
&gt;=C2=A0 =C2=A0 * regular size:=C2=A0 3117183743<br>
&gt;=C2=A0 =C2=A0 * regular avg:=C2=A0 6701.372750217131<br>
&gt;=C2=A0 =C2=A0 * regular median:=C2=A0 1734<br>
&gt;=C2=A0 =C2=A0 * regular max:=C2=A0 67533<br>
&gt;=C2=A0 =C2=A0 * extended size:=C2=A0 <a href=3D"tel:(385)%20886-3413" v=
alue=3D"+13858863413" target=3D"_blank">3858863413</a><br>
&gt;=C2=A0 =C2=A0 * extended avg:=C2=A0 8295.847872541684<br>
&gt;=C2=A0 =C2=A0 * extended median:=C2=A0 2041<br>
&gt;=C2=A0 =C2=A0 * extended max:=C2=A0 52508<br>
&gt;<br>
&gt;In order to consider the average+median filter sizes in a world worth<b=
r>
&gt;larger blocks, I also ran the index for testnet:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 * total size:=C2=A0 2753238530<br>
&gt;=C2=A0 =C2=A0 * total avg:=C2=A0 5918.95736054141<br>
&gt;=C2=A0 =C2=A0 * total median:=C2=A0 60202<br>
&gt;=C2=A0 =C2=A0 * total max:=C2=A0 74983<br>
&gt;=C2=A0 =C2=A0 * regular size:=C2=A0 1165148878<br>
&gt;=C2=A0 =C2=A0 * regular avg:=C2=A0 2504.856172982827<br>
&gt;=C2=A0 =C2=A0 * regular median:=C2=A0 24812<br>
&gt;=C2=A0 =C2=A0 * regular max:=C2=A0 64554<br>
&gt;=C2=A0 =C2=A0 * extended size:=C2=A0 1588089652<br>
&gt;=C2=A0 =C2=A0 * extended avg:=C2=A0 3414.1011875585823<br>
&gt;=C2=A0 =C2=A0 * extended median:=C2=A0 35260<br>
&gt;=C2=A0 =C2=A0 * extended max:=C2=A0 41731<br>
&gt;<br>
&gt;Finally, here are the testnet stats which take into account the<br>
&gt;increase<br>
&gt;in the maximum filter size due to segwit&#39;s block-size increase. The=
 max<br>
&gt;filter sizes are a bit larger due to some of the habitual blocks I<br>
&gt;created last year when testing segwit (transactions with 30k inputs,<br=
>
&gt;30k<br>
&gt;outputs, etc).<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0* total size:=C2=A0 585087597<br>
&gt;=C2=A0 =C2=A0 =C2=A0* total avg:=C2=A0 520.8839608674402<br>
&gt;=C2=A0 =C2=A0 =C2=A0* total median:=C2=A0 20<br>
&gt;=C2=A0 =C2=A0 =C2=A0* total max:=C2=A0 164598<br>
&gt;=C2=A0 =C2=A0 =C2=A0* regular size:=C2=A0 299325029<br>
&gt;=C2=A0 =C2=A0 =C2=A0* regular avg:=C2=A0 266.4790836307566<br>
&gt;=C2=A0 =C2=A0 =C2=A0* regular median:=C2=A0 13<br>
&gt;=C2=A0 =C2=A0 =C2=A0* regular max:=C2=A0 164583<br>
&gt;=C2=A0 =C2=A0 =C2=A0* extended size:=C2=A0 285762568<br>
&gt;=C2=A0 =C2=A0 =C2=A0* extended avg:=C2=A0 254.4048772366836<br>
&gt;=C2=A0 =C2=A0 =C2=A0* extended median:=C2=A0 7<br>
&gt;=C2=A0 =C2=A0 =C2=A0* extended max:=C2=A0 127631<br>
&gt;<br>
&gt;For those that are interested in the raw data, I&#39;ve uploaded a CSV =
file<br>
&gt;of raw data for each block (mainnet + testnet), which can be found<br>
&gt;here:<br>
&gt;=C2=A0 =C2=A0 =C2=A0* mainnet: (14MB):<br>
&gt;<a href=3D"https://www.dropbox.com/s/4yk2u8dj06njbuv/mainnet-gcs-stats.=
csv?dl=3D0" rel=3D"noreferrer" target=3D"_blank">https://www.dropbox.com/s/=
4yk2u8dj06njbuv/mainnet-gcs-stats.csv?dl=3D0</a><br>
&gt;=C2=A0 =C2=A0 =C2=A0* testnet: (25MB):<br>
&gt;<a href=3D"https://www.dropbox.com/s/w7dmmcbocnmjfbo/gcs-stats-testnet.=
csv?dl=3D0" rel=3D"noreferrer" target=3D"_blank">https://www.dropbox.com/s/=
w7dmmcbocnmjfbo/gcs-stats-testnet.csv?dl=3D0</a><br>
&gt;<br>
&gt;<br>
&gt;We look forward to getting feedback from all of y&#39;all!<br>
&gt;<br>
&gt;-- Laolu<br>
&gt;<br>
&gt;<br>
&gt;[1]: <a href=3D"https://github.com/lightninglabs/neutrino" rel=3D"noref=
errer" target=3D"_blank">https://github.com/lightninglabs/neutrino</a><br>
&gt;[2]: <a href=3D"https://github.com/Roasbeef/btcd/tree/segwit-cbf" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/Roasbeef/btcd/tree/seg=
wit-cbf</a><br>
&gt;[3]: <a href=3D"https://github.com/Roasbeef/btcutil/tree/gcs/gcs" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/Roasbeef/btcutil/tree/=
gcs/gcs</a><br>
&gt;[4]: <a href=3D"https://github.com/lightningnetwork/lnd/" rel=3D"norefe=
rrer" target=3D"_blank">https://github.com/lightningnetwork/lnd/</a><br>
&gt;<br>
&gt;-- Laolu<br>
</blockquote></div>

--94eb2c12992af95ec60550ed4efb--