From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 05C5EC3A for ; 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 ; 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: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: 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 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: To: Bitcoin Protocol Discussion , Gregory Maxwell In-Reply-To: Message-Id: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = het volgende geschreven: >=20 > On Wed, May 16, 2018 at 4:36 PM, Cory Fields via bitcoin-dev > 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