From: Sjors Provoost <sjors@sprovoost.nl>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Thu, 7 Jun 2018 11:39:59 +0200
References: <CAApLimjfPKDxmiy_SHjuOKbfm6HumFPjc9EFKvw=3NwZO8JcmQ@mail.gmail.com>
	<CAAS2fgTHTK8Dve9xHW9yULa1yObWtmwmeKKcD_BMjON=RAw8Sg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Gregory Maxwell <greg@xiph.org>
In-Reply-To: <CAAS2fgTHTK8Dve9xHW9yULa1yObWtmwmeKKcD_BMjON=RAw8Sg@mail.gmail.com>
Message-Id: <E5BD6DC6-281B-46E5-ABD3-71B2D5549902@sprovoost.nl>
Subject: Re: [bitcoin-dev] UHS: Full-node security without maintaining a
 full UTXO set
Precedence: list

eMMC storage, which low end devices often use, come in 2x increments. =
Running a pruned full node on 8 GB is difficult if not impossible (the =
UTXO set peaked at 3.5 GB in January, but a full node stores additional =
stuff).

However, 16 GB is only =E2=82=AC10 more expensive and presumably =
standard by the time this would be rolled out.

On AWS every GB of SSD storage avoided saves $1 per year, not end of the =
world stuff, but not negligible either. Outbound traffic costs $0.10 / =
GB (ignoring free allowance), so when uploading 200 GB per year, the 5% =
would offset $1 of storage cost savings.

The above seems marginal, probably not worth it unless there=E2=80=99s =
really no downside.

What I find attractive about this proposal is the ability to squeeze =
more out of limited RAM (typically only 1 or 2 GB on these low end =
devices). I=E2=80=99d have to test Cory=E2=80=99s branch to see if that =
actually matters in practice.

It=E2=80=99s also useful to distinguish benefits during initial sync =
from ongoing operation. The former I=E2=80=99ve almost given up on for  =
low end devices (can take weeks), in favor of doing it on a faster =
computer and copying the result. The latter needs far less RAM, so =
perhaps this proposal doesn=E2=80=99t help much there, but that would be =
useful to measure.

Did you try the recent SHA256 optimizations on your branch?

Sjors

> Op 17 mei 2018, om 18:56 heeft Gregory Maxwell via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven:
>=20
> On Wed, May 16, 2018 at 4:36 PM, Cory Fields via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Tl;dr: Rather than storing all unspent outputs, store their hashes.
>=20
> My initial thoughts are it's not _completely_ obvious to me that a 5%
> ongoing bandwidth increase is actually a win to get something like a
> 40% reduction in the size of a pruned node (and less than a 1%
> reduction in an archive node) primarily because I've not seen size of
> a pruned node cited as a usage limiting factor basically anywhere. I
> would assume it is a win but wouldn't be shocked to see a careful
> analysis that concluded it wasn't.
>=20
> But perhaps more interestingly, I think the overhead is not really 5%,
> but it's 5% measured in the context of the phenomenally inefficient tx
> mechanisms ( https://bitcointalk.org/index.php?topic=3D1377345.0 ).
> Napkin math on the size of a txn alone tells me it's more like a 25%
> increase if you just consider size of tx vs size of
> tx+scriptpubkeys,amounts.  If I'm not missing something there, I think
> that would get in into a very clear not-win range.
>=20
> On the positive side is that it doesn't change the blockchain
> datastructure, so it's something implementations could do without
> marrying the network to it forever.
>=20