diff options
author | Simon Selitsky <simon@coingyft.com> | 2016-01-25 10:57:53 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2016-01-25 15:57:57 +0000 |
commit | 2d7a499f7272cb7cfa252849bc0a1ae666b9cfb5 (patch) | |
tree | f5ec793fd43a7d373c0362788f28f28d493b3a3f | |
parent | 127ae18bc2fc95c112140dbaa954370791795ce1 (diff) | |
download | pi-bitcoindev-2d7a499f7272cb7cfa252849bc0a1ae666b9cfb5.tar.gz pi-bitcoindev-2d7a499f7272cb7cfa252849bc0a1ae666b9cfb5.zip |
Re: [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available
-rw-r--r-- | bf/cccf946682b29b5d83effa0a3c00986e4619cc | 204 |
1 files changed, 204 insertions, 0 deletions
diff --git a/bf/cccf946682b29b5d83effa0a3c00986e4619cc b/bf/cccf946682b29b5d83effa0a3c00986e4619cc new file mode 100644 index 000000000..64f1f1e09 --- /dev/null +++ b/bf/cccf946682b29b5d83effa0a3c00986e4619cc @@ -0,0 +1,204 @@ +Return-Path: <simon@coingyft.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 424C4DB3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 25 Jan 2016 15:57:57 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com + [209.85.192.41]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7690D79 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 25 Jan 2016 15:57:56 +0000 (UTC) +Received: by mail-qg0-f41.google.com with SMTP id e32so112247936qgf.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 25 Jan 2016 07:57:56 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=coingyft-com.20150623.gappssmtp.com; s=20150623; + h=content-type:mime-version:subject:from:in-reply-to:date:cc + :content-transfer-encoding:message-id:references:to; + bh=M1//lV98vuZBiheKT1HDp4q9nlJu+3V5E5zDNGkJX3g=; + b=vhasbyfhTdITAwycCxgtuXBYoDfMy3vAxneo4UGRI0IwrJ+8P4kPGYzNutOdN/UpxP + VSOKUYGwd3Nx6Msi55lqoGsczacaMERTbt5owuaxOdrJWHYruzzpy34Pn+Bw6r19xGU1 + 6vwp1iGYcXC4alPMJJCGQTl2thRwGUDK6ENDNedvAkA+tnVgdD07tcqL6ems0FBV23u8 + Gts/LjjkrR6M3yocLS1N07EECnhg9J38c3MbFz17c6yb+fx5XjCZnYEZWkNTrZOboQgU + tlZG6xqHe9KGYVq6k0lstpKdF5QrLwrAQY34EkcNp8rEZ0Ige6GB7Gnog5j6W77vVaEb + EfuA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:content-type:mime-version:subject:from + :in-reply-to:date:cc:content-transfer-encoding:message-id:references + :to; bh=M1//lV98vuZBiheKT1HDp4q9nlJu+3V5E5zDNGkJX3g=; + b=Xki+CgATTYxmBazAKhkvWCaTpWwmnYKf4h8lc9mfdlHjr37WQ5iIlqtQhqjbGckDbj + nuuV9fVrRTHnqEbxaOmDt14eyYck3w1CIBS+b2v/KCHwX4FYbr1nfLmbRsuF0TmjuJrd + ml82qWQLFMVvFy+ZweSlh3huX1bBTUgX8Oj1SV/uySNfYeSWrNX5UUYwEnk5Nh0M13+E + JUM78wVRArdOtqHdN5jsc82KpKoF2QRvcSxipUaqzEW4qVng+JzpdEB7VgRFoyhdDDh/ + aDJ23W11pNEfLmRuTLR2MB88d0MJRvjQDoaj6yHc9FV11uJAGaeUwZx/a9zFZxK4t5en + eQKw== +X-Gm-Message-State: AG10YOTVphUHKYvmd/wi4pU0Ra6SltMpjSEG7XnnhjQc3j/yCvT6B64dERC3uJm+Gmc2Lg== +X-Received: by 10.140.134.197 with SMTP id 188mr23787248qhg.58.1453737475401; + Mon, 25 Jan 2016 07:57:55 -0800 (PST) +Received: from [192.168.2.140] (pool-100-0-197-194.bstnma.fios.verizon.net. + [100.0.197.194]) + by smtp.gmail.com with ESMTPSA id l19sm724577qki.42.2016.01.25.07.57.54 + (version=TLSv1/SSLv3 cipher=OTHER); + Mon, 25 Jan 2016 07:57:54 -0800 (PST) +Content-Type: text/plain; + charset=us-ascii +Mime-Version: 1.0 (1.0) +From: Simon Selitsky <simon@coingyft.com> +X-Mailer: iPad Mail (13D15) +In-Reply-To: <20160125150559.GA28847@amethyst.visucore.com> +Date: Mon, 25 Jan 2016 10:57:53 -0500 +Content-Transfer-Encoding: quoted-printable +Message-Id: <2A118822-6550-4042-9229-1D213B6FE615@coingyft.com> +References: <20160117100808.GA4299@amethyst.visucore.com> + <1591452.8UA7xN1qih@1337h4x0r> + <20160125120317.GB17769@amethyst.visucore.com> + <2815165.aykQg88K5r@1337h4x0r> + <20160125150559.GA28847@amethyst.visucore.com> +To: "Wladimir J. van der Laan" <laanwj@gmail.com> +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, MIME_QP_LONG_LINE, + 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: Mon, 25 Jan 2016 16:05:20 +0000 +Cc: bitcoin-dev@lists.linuxfoundation.org +Subject: Re: [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development 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: Mon, 25 Jan 2016 15:57:57 -0000 + +>> Block data that is stored can be used by other software, or potentially b= +e +>> served to other nodes. The latter is not implemented at the moment - it w= +ould require a change to the P2P protocol, thus right now pruning nodes don'= +t serve block data at all. + +Why is the minimum storage quota of 550 MiB necessary for pruning nodes +if the block data is not served to other nodes ? Could the client just do tr= +ansaction verification and transaction relaying and only keep the block(s)=20= + +being verified on disk ? + + +On Jan 25, 2016, at 10:05 AM, Wladimir J. van der Laan via bitcoin-dev <bitc= +oin-dev@lists.linuxfoundation.org> wrote: + +>>> To enable block pruning set prune=3D<N> on the command line or in +>>> bitcoin.conf, where N is the number of MiB to allot for raw block & undo= + +>>> data. +>=20 +>> =46rom having read the Bitcoin whitepaper quite a few months ago ago, I h= +ave the=20 +>> very very basic understanding that pruning is meant to: +>> - delete old transaction data which merely "moves coins around" +>> - instead only store the "origin" (=3D block where coins were mined) and=20= + +>> "current location" of the coins, i.e. the unspent transactions. Notably, I= +=20 +>> understood it as "this is as secure as storing everything, since we know w= +here=20 +>> the coins were created, and where they are". +>>=20 +>> So from that point of view, I would assume that there is a "natural" amou= +nt of=20 +>> megabytes which a fully pruned blockchain consists of: It would be define= +d by=20 +>> the final amount of unspent coins. +>> I thereby am confused why it is possible to configure a number of megabyt= +es=20 +>> "to allot for raw block & undo data". I would rather expect pruning just t= +o be=20 +>> a boolean on/off flag, and the number of megabytes to be an automatically= +=20 +>> computed result from the natural size of the dataset. +>> And especially, I fear that I could set N too low, and as a result, it wo= +uld=20 +>> delete "too much". I mean could this result in even security relevant=20 +>> transaction data being deleted? +>=20 +> The term 'pruning', unfortunately is very much overused and overloaded in t= +he +> bitcoin ecosystem. Satoshi's paper refers to UTXO pruning. This is Pieter W= +uille's "ultraprune", +> which has been part of Bitcoin Core for more than three years. +>=20 +> Block pruning is not mentioned in that paper because it is just administra= +tive, +> the only reason that nodes store historical blocks at all is to serve it t= +o other nodes, +> as well as to catch up the wallet status and for -reindexes. +>=20 +>> Thus, it would be nice if you could yet once more edit the release notes t= +o: +>=20 +> I don't have time to work on the release notes right now, but if someone e= +lse +> wants to contribute that'd be awesome. +>=20 +>> - explain why a N must be given +>=20 +> To give a quotum. The point is that the user can choose how much harddisk s= +pace they want to +> dedicate to block storage. +>=20 +> Block data that is stored can be used by other software, or potentially be= + +> served to other nodes. The latter is not implemented at the moment - it wo= +uld require +> a change to the P2P protocol, thus right now pruning nodes don't serve blo= +ck +> data at all. +>=20 +>> - what a "safe" value of N is. I.e. how large must N be at least to not d= +elete=20 +>> security-relevant stuff? +>=20 +> There is no security compromise with pruning. Any value of N is intended t= +o be safe. +>=20 +> Very low values would delete undo data that may be necessary in a reorgani= +zation, +> but this is prohibited by argument checks. +>=20 +> Release notes are not meant as a replacement or supplement for documentati= +on. +> The documentation for -prune is this: +>=20 +> -prune=3D<n> +> Reduce storage requirements by pruning (deleting) old blocks. This m= +ode +> is incompatible with -txindex and -rescan. Warning: Reverting this +> setting requires re-downloading the entire blockchain. (default: 0 =3D= + +> disable pruning blocks, >550 =3D target size in MiB to use for block= + +> files) +>=20 +>> - maybe mention if there is a "auto" setting for N to ensure that it chos= +es a=20 +>> safe value on its own? +>=20 +> As said, there is no safe or unsafe value. The lowest acceptable value is j= +ust as safe +> as storing everything. +>=20 +> Wladimir +>=20 +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + |