Add two hour buffer to manual pruning #9778

1. 
   morcos commented at 4:11 PM on February 16, 2017: member

   @gmaxwell, this is meant to address #9761 (comment)

   Should probably go in 0.14 with the rest of the grace period / importmulti changes

2. in src/rpc/blockchain.cpp:None in 051fc42521 outdated

    819 | @@ -820,7 +820,8 @@ UniValue pruneblockchain(const JSONRPCRequest& request)
    820 |          throw runtime_error(
    821 |              "pruneblockchain\n"
    822 |              "\nArguments:\n"
    823 | -            "1. \"height\"       (numeric, required) The block height to prune up to. May be set to a discrete height, or to a unix timestamp to prune based on block time.\n"
    824 | +            "1. \"height\"       (numeric, required) The block height to prune up to. May be set to a discrete height, or a unix timestamp\n"
    825 | +            "                  to prune based on block time. Timestamp based pruning automatically adds a 2 hour buffer.\n"
   

   ---

   ---

   

   ryanofsky commented at 4:32 PM on February 16, 2017:

   I'd maybe make the comment more literal and say timestamp pruning will only prune blocks that are at least 2 hours older than the provided timestamp (instead of that timestamp pruning automatically adds a 2 hour buffer).

3. ryanofsky approved
4. 
   ryanofsky commented at 4:34 PM on February 16, 2017: member

   utACK 051fc42521dd5417f34ed27a727ad045a9823764

   I think it should probably not be hard to add a test for this in: https://github.com/bitcoin/bitcoin/blob/1e92e041ddc8232bcf64f09fd70891b80ac05c66/qa/rpc-tests/pruning.py#L229

   Though pruning.py is kind of a pain to run.

5. fanquake added the label RPC/REST/ZMQ on Feb 16, 2017
6. fanquake added this to the milestone 0.14.0 on Feb 16, 2017
7. jonasschnelli approved
8. 
   jonasschnelli commented at 7:12 PM on February 16, 2017: contributor

   code review utACK 051fc42521dd5417f34ed27a727ad045a9823764

9. 
   jtimon commented at 9:00 PM on February 16, 2017: contributor

   Maybe 7200 could be made a constant to be reused in #9761 ? (and the normal rescan?) Also agree with @ryanofsky 's nit, and, yes, a test would be nice (although, yeah, prunning.py is a pita). utACK 051fc42

10. Add two hour buffer to manual pruning 91fb506e0a
11. morcos force-pushed on Feb 16, 2017
12. 
    morcos commented at 10:49 PM on February 16, 2017: member

    ok slightly modified the help text otherwise unchanged from ACK'ed commit

    The 7200 number was added simultaneously in 3 separate PR's, but I agree it should be cleaned up to a constant in a later PR.

13. 
    morcos commented at 10:52 PM on February 16, 2017: member

    Actually my personal preference would have been to leave the details of the exact buffering mechanism used off the help text. It seems too dependent on the exact implementation choice, and there is nothing magical about the 2 hour number. But at this point I think we are bike shedding.

14. 
    gmaxwell commented at 2:59 AM on February 17, 2017: contributor

    utACK you could also leave it out of the description as far as I care, it's an implementation detail.

15. 
    laanwj commented at 11:50 AM on February 17, 2017: member

    I think it's fine to mention it in the description. The two hours could be important in edge cases e.g. determining what blocks to keep with manual pruning.

16. 
    laanwj commented at 11:51 AM on February 17, 2017: member

    utACK 91fb506

17. laanwj merged this on Feb 17, 2017
18. laanwj closed this on Feb 17, 2017

    ---

19. laanwj referenced this in commit ad168ef4e3 on Feb 17, 2017
20. 
    morcos commented at 4:51 PM on February 21, 2017: member

    This caused pruning.py to break. @ryanofsky or I will fix the test.

21. codablock referenced this in commit cd501a1e64 on Jan 19, 2018
22. codablock referenced this in commit 0080fde36a on Jan 23, 2018
23. andvgal referenced this in commit 783fc0550a on Jan 6, 2019
24. CryptoCentric referenced this in commit dbc4dbea45 on Feb 27, 2019
25. MarcoFalke locked this on Sep 8, 2021

Milestone
0.14.0