< CubicEarths> Would it be reasonable to have an option where discarding blocks under pruned mode was conditional on an RPC message specifying each block to be thrown out?
< CubicEarths> The benefit being something like a lightning node could decide when it no longer needed a block, and let Bitcoin know
< sipa> CubicEarths: already exists
< sipa> CubicEarths: just specify -prune rather than -prune=size, and call the pruneblockchain RPC
< CubicEarths> sipa: amazing :)
< luke-jr> sipa: not exactly the same thing IMO
< luke-jr> at least as I imagine it, there would be a way for software to define "prune locks" that set a maximum height to prune to; and then those locks can be updated by the software as it scans
< luke-jr> thus, each wallet (even not loaded) could have a persistent prune lock set until it's updated
< luke-jr> or external programs like Lightning daemons etc
< sipa> luke-jr: yeah, a per-user way of specifying prunability rather than globally would make sense
< bitcoin-git> [bitcoin] ken2812221 opened pull request #13482: Remove boost::program_options dependency (master...program_options) https://github.com/bitcoin/bitcoin/pull/13482
< CubicEarths> luke-jr: sipa: Are you taking about a way to only prune if all locks from different users up to a given height are lifted?
< luke-jr> right
< CubicEarths> I see a funny irony in that concept, since the more users / clients had locks, the less pruning would happen :)
< CubicEarths> It could be useful for a small handful of users tough
< luke-jr> useful for lots of things
< luke-jr> eg, it would enable Armory to prune
< CubicEarths> For a single user, why is pruneblockchain any different?
< luke-jr> I suppose that's workable too
< luke-jr> but it would also make it more feasible to have external indexes too
< CubicEarths> That too wouldn't be the same for a single client?
< luke-jr> you wouldn't have a single client
< luke-jr> the index would be one client, and your wallet another
< CubicEarths> I see.
< CubicEarths> Do you agree though, that if you have many clients, you are probably better off just leaving things unpruned? I mean you could allow pruning, but it would only prune as far as the most needy client allowed.
< CubicEarths> Again, it could be very effective for a small number of clients
< luke-jr> CubicEarths: the goal would be to have everything catch up reasonably
< cfields> I'll be away Mon-Fri and won't have my laptop on me, but I'll try to keep up with responses on github/mail. Not that I've been very productive lately anyway. Hoping a few days away will break me out of my slump :)
< fanquake> cfields Have a good time!
< fanquake> I'll make sure to harass you the second you are back :p
< cfields> fanquake: heh, thanks. I tried to knock out a bunch of yours this week, but I know there are several still outstanding.
< fanquake> cfields np, I've got a few more changes to PR over the weekend. Need to follow up with you about some non-Core related stuff too.
< rk3y> but lets stay in contact: mine is rk3y at protonmail.com
< fanquake> rk3y: wrong channel?
< provoostenator> luke-jr: having control over when which block gets pruned certainly seems useful, see e.g. discussion here: https://github.com/ElementsProject/lightning/issues/1502#issuecomment-390633666
< provoostenator> Even if it's just "blocks below height are now safe to prune for lock N"
< provoostenator> Somewhat related would be the ability to refetch a specific pruned block: https://github.com/ElementsProject/lightning/issues/1297#issuecomment-394228514
< provoostenator> Keeping track of these locks in a robust way seems potentially tricky though. It should probably abandon a lock if a max disk storage threshold is about to be exceeded.
< rk3y> fanquake: sorry strange shortcut + human copy paste error
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/81069a75bd71...fa2ea37940ed
< bitcoin-git> bitcoin/master 9e2e562 Loganaden Velvindron: Fix CVE-2018-12356 by hardening the regex.
< bitcoin-git> bitcoin/master fa2ea37 Wladimir J. van der Laan: Merge #13479: contrib: Fix CVE-2018-12356 by hardening the regex...
< bitcoin-git> [bitcoin] laanwj closed pull request #13479: contrib: Fix CVE-2018-12356 by hardening the regex (master...master) https://github.com/bitcoin/bitcoin/pull/13479
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/fa2ea37940ed...a90ca4087a6f
< bitcoin-git> bitcoin/master 634bd97 practicalswift: Explicitly specify encoding when opening text files in Python code
< bitcoin-git> bitcoin/master c8176b3 practicalswift: Add linter: Make sure we explicitly open all text files using UTF-8 or ASCII encoding in Python
< bitcoin-git> bitcoin/master a90ca40 Wladimir J. van der Laan: Merge #13448: Add linter: Make sure we explicitly open all text files using UTF-8 encoding in Python...
< bitcoin-git> [bitcoin] laanwj closed pull request #13448: Add linter: Make sure we explicitly open all text files using UTF-8 encoding in Python (master...lint-python-utf8-encoding) https://github.com/bitcoin/bitcoin/pull/13448
< sipa> provoostenator: look at jonasschnelli's auxiliary blocks
< provoostenator> sipa: #9171?
< gribble> https://github.com/bitcoin/bitcoin/issues/9171 | Introduce auxiliary block requests by jonasschnelli · Pull Request #9171 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] luke-jr closed pull request #10730: Move script flag to/from-string logic from tests to script/interpreter (master...scriptflag_strings) https://github.com/bitcoin/bitcoin/pull/10730
< bitcoin-git> [bitcoin] ken2812221 opened pull request #13485: Ensure that event loop is empty before the loop exit (master...http_shutdown) https://github.com/bitcoin/bitcoin/pull/13485
< bitcoin-git> [bitcoin] ken2812221 closed pull request #13390: Tests: Ignore RemoteDisconnected and BadStatusLine when stopping node (master...stop_node) https://github.com/bitcoin/bitcoin/pull/13390