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 55249E0D for ; Mon, 25 Jan 2016 14:44:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D44868A for ; Mon, 25 Jan 2016 14:44:08 +0000 (UTC) Received: by mail-io0-f172.google.com with SMTP id 1so153364598ion.1 for ; Mon, 25 Jan 2016 06:44:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=OdcbhHBUKNMLI668QD5449VImvJpnCzSIHbe2kXj0RQ=; b=iIs9TiNcPy29j/TfCgzuZgBpsTLDoejWcscpLI87dXkukfi+nsx4lolDSPelmtb5B4 U2EElaM1CdmYvokWZnx941pDc6nPBQQbYoz2zue1ZcJSt/sSyOPCnyD27U4KTGPUXegK 0QLG8q8Hake20rXGjbpSOiY4z9XY3aD6tPdqg//FrGmh+4cG+yeykilSiueq6nHvfQa/ 3/NFin64CWA7xJ8RTk+ZJLzkRFFuN+VCQzKGIdNrfljrGr2DTfchnbdodVkU7NRTHzug j8fq5a47RsccTBErgI3Awa18wfvQi7ItPtoYNPT4J94E5mfOXwTzYXvTJBL3QDVLf5MQ bGsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=OdcbhHBUKNMLI668QD5449VImvJpnCzSIHbe2kXj0RQ=; b=PpZw2p45DkYs2Q1uB8pUdPLuFGRQ2UacYi0ZMXOMTMlRWaI7J4yvoaFEbLxi8JgB/f kcv/z9TYMXkTU2/Sna0bU6a/tLlDjYggwJmT6Unug/9jil49uez3poQatlSQzFccT4GU JXC1Fa+SgW9QD2KlTuluRLHltPRc0Ah9VCgkepIMlF3VOEnLoWCIi4lt9G++H97WzCMn NtEd+Q9oe6l3lDDmMuHB0l9t9Kmzxqw/7O/YsjsuUCL46dRHK2eGjZy+bR5C6gyOOop/ kz6YfYMqwIoH/SfidiD7Pnt/PvRchBqR8Fk6ahnBkeOY0uPZaidW7iHTm3epIGVQ7nrt zE3w== X-Gm-Message-State: AG10YOT5yY2qclTL1wj6WkxMaOq76RFhq+KQvTBGOk6uod38KCeTK+Cia1vWRqDmE6XJV1Peu0md8CS7kCHQ2w== MIME-Version: 1.0 X-Received: by 10.107.154.79 with SMTP id c76mr16367469ioe.53.1453733048274; Mon, 25 Jan 2016 06:44:08 -0800 (PST) Received: by 10.64.90.7 with HTTP; Mon, 25 Jan 2016 06:44:08 -0800 (PST) In-Reply-To: <2815165.aykQg88K5r@1337h4x0r> References: <20160117100808.GA4299@amethyst.visucore.com> <1591452.8UA7xN1qih@1337h4x0r> <20160125120317.GB17769@amethyst.visucore.com> <2815165.aykQg88K5r@1337h4x0r> Date: Mon, 25 Jan 2016 15:44:08 +0100 Message-ID: From: Marco Falke Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, MISSING_HEADERS, RCVD_IN_DNSWL_LOW autolearn=no 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:11 +0000 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 14:44:09 -0000 All of this is already implemented in the bitcoind and bitcoin gui. The theoretic minimum for the prune target would be 0 (just the header of the current best block) as Bitcoin Core already stores the chainstate (about 2 GiB) regardless of what you set for -prune=. In practice, the minimum is 510, so reorgs and small rescans (may not be implemented in 0.12) are still possible. The clients won't let you set it below that target: "Prune configured below the minimum of 550 MiB. Please use a higher number." Also, keep in mind Bitcoin Core comes with a help message explaining -prune and other command line options --Marco 2016-01-25 13:27 GMT+01:00 xor--- via bitcoin-dev : > On Monday, January 25, 2016 01:03:17 PM Wladimir J. van der Laan wrote: >> > If yes, I would highly recommend advertising it in the new release notes - >> > as said, the disk space reduction is a big deal. >> >> Good idea, has been added by Marco Falke in commit fa31133, > > Thanks. The RC2 changelog now says: > >> To enable block pruning set prune= on the command line or in >> bitcoin.conf, where N is the number of MiB to allot for raw block & undo >> data. > > From having read the Bitcoin whitepaper quite a few months ago ago, I have the > very very basic understanding that pruning is meant to: > - delete old transaction data which merely "moves coins around" > - instead only store the "origin" (= block where coins were mined) and > "current location" of the coins, i.e. the unspent transactions. Notably, I > understood it as "this is as secure as storing everything, since we know where > the coins were created, and where they are". > > So from that point of view, I would assume that there is a "natural" amount of > megabytes which a fully pruned blockchain consists of: It would be defined by > the final amount of unspent coins. > I thereby am confused why it is possible to configure a number of megabytes > "to allot for raw block & undo data". I would rather expect pruning just to be > a boolean on/off flag, and the number of megabytes to be an automatically > 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 would > delete "too much". I mean could this result in even security relevant > transaction data being deleted? > > Thus, it would be nice if you could yet once more edit the release notes to: > - explain why a N must be given > - what a "safe" value of N is. I.e. how large must N be at least to not delete > security-relevant stuff? > - maybe mention if there is a "auto" setting for N to ensure that it choses a > safe value on its own? > > Sorry if my descriptions are from a layman's point of view. I intentionally > did *not* re-read the Bitcoin whitepaper to have a better understanding: > I think having a layman's understanding is a good usability test for such > stuff. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >