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
|
Return-Path: <sjors@sprovoost.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 05C5EC3A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Jun 2018 09:46:14 +0000 (UTC)
X-Greylist: delayed 00:06:10 by SQLgrey-1.7.6
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
[66.111.4.25])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E52065E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 7 Jun 2018 09:46:12 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.nyi.internal (Postfix) with ESMTP id D2B6A21C1D;
Thu, 7 Jun 2018 05:40:01 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
by compute1.internal (MEProxy); Thu, 07 Jun 2018 05:40:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h=
content-transfer-encoding:content-type:date:from:in-reply-to
:message-id:mime-version:references:subject:to:x-me-sender
:x-me-sender:x-sasl-enc; s=fm2; bh=XmH4MCC7wRKscq8oMpIt7lpzuTm5n
6yLUxNbL5i7OmU=; b=qrws8lOVX33pqHvln/yMib+RWhIdTOBg990YfISlNK82S
KSUe+XL2Bl7q3RT3SKn/3ecYTks451w0fNDp4SwnnN9QtVSRZoOQBJQZ80VWDn7i
0GeE3nk59XF8xsaVTHsvQPr33HNKstKtrrYnEAygIEqmuQ5Xpv7dgiTpXchrJiuH
wNzOFEi3Xnzjz3P34ZtDXzHRujRjGhaVOaspBkivAjGMDFpkXXozJ8jlSYCWtnTB
iSl35A2c01FZZDnEJN9YVMszNadYonunB5cnQtYoJpsEz/t3g3Yvhdcv/KaZ46Uz
Yuxlwc2+b2IUszE26QwFZhecfnq8tDXtAE0O+JaBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=XmH4MC
C7wRKscq8oMpIt7lpzuTm5n6yLUxNbL5i7OmU=; b=BqNTKvUImUunQwQxxULmpG
ZzALnorztyUvpDhr9TSNOMaJlVbuttXe8qswEqInp3Zq+vx8NQ250pYYPiFPwQ4P
AOhGsa5RYZb4GPlcrygMFx+mIk2gtaJpi1x2vxSaXVHR+RTmJoDD31W1eEnwMIW+
2U66P/WGT/ncl2oDkGEeKu2AZB+wAywaJn3wreCkhjV5yIbMLDcmKr4t0MM0zW+K
oN00A+sUtoJYBpCRIsX0jXYt8Fl5j3YVo21urBThLRK25IFWakJa2xJv0Sd8dTwi
L3BvqDcZnTkPeX8J5mKptFwi8KmaQ2+zLW15MzrwtZ02z5n1tc/9icSA0G8XeUow
==
X-ME-Proxy: <xmx:cf0YWwnLNxg4eOG-OADTO86oFVniB02xfoEoKUsGGUeVZ7edyvhr9g>
X-ME-Proxy: <xmx:cf0YW4wGPlRdo6MvKFdVpFZhThz1CsPWwaZo2iS6e1wA-zotZM1gTQ>
X-ME-Proxy: <xmx:cf0YWwl98qahn0X7TkD5QKXQkq91FY87SqtLNAZ_PRNiiFI-VknJRQ>
X-ME-Proxy: <xmx:cf0YW5cFdt_GWJfN7VfkHAszKYTf_PggVf2StJ6hhikJPNmCB_zclg>
X-ME-Proxy: <xmx:cf0YW-oCTPk5xpLgjTG9QfuXmShmAcyJpk9AlClREYriXy6WHwtt4g>
X-ME-Proxy: <xmx:cf0YW5gds6j5Ev1ZouhTYoEEeJxHB_oRC0AruGVCnaa6KbharAFSSQ>
X-ME-Sender: <xms:cf0YW0_2XsCSrUsOUtIUeWg4mHHzhOv_PGBSoQYVJ8WGj40S5EaS4w>
Received: from [192.168.178.185] (54693d0f.cm-12-2a.dynamic.ziggo.nl
[84.105.61.15])
by mail.messagingengine.com (Postfix) with ESMTPA id DBA9AE46DC;
Thu, 7 Jun 2018 05:40:00 -0400 (EDT)
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>
X-Mailer: Apple Mail (2.3445.8.2)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 07 Jun 2018 14:01:26 +0000
Subject: Re: [bitcoin-dev] UHS: Full-node security without maintaining a
full UTXO set
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, 07 Jun 2018 09:46:14 -0000
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
|
