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 424C4DB3 for ; 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 ; Mon, 25 Jan 2016 15:57:56 +0000 (UTC) Received: by mail-qg0-f41.google.com with SMTP id e32so112247936qgf.3 for ; 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 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: >>> To enable block pruning set prune=3D 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 > 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