summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSimon Selitsky <simon@coingyft.com>2016-01-25 10:57:53 -0500
committerbitcoindev <bitcoindev@gnusha.org>2016-01-25 15:57:57 +0000
commit2d7a499f7272cb7cfa252849bc0a1ae666b9cfb5 (patch)
treef5ec793fd43a7d373c0362788f28f28d493b3a3f
parent127ae18bc2fc95c112140dbaa954370791795ce1 (diff)
downloadpi-bitcoindev-2d7a499f7272cb7cfa252849bc0a1ae666b9cfb5.tar.gz
pi-bitcoindev-2d7a499f7272cb7cfa252849bc0a1ae666b9cfb5.zip
Re: [bitcoin-dev] Bitcoin Core 0.12.0 release candidate 1 available
-rw-r--r--bf/cccf946682b29b5d83effa0a3c00986e4619cc204
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
+