Better manual pruning when multiple clients require unpruned history #18599

Is your feature request related to a problem? Please describe. Some clients that use a bitcoin node might require full block data for blocks they have not retrieved yet. A common solution to this is to use manual pruning with the "pruneblockchain" RPC, making the client responsible for pruning blocks once they are no longer needed. However, this does not work when multiple clients are involved. For example, if we have both c-lightning and wasabi wallet syncing against the pruned node, c-lightning has the possibility of pruning blocks that wasabi wallet still needs.

Describe the solution you'd like The best solution I can imagine would be something like the keepheight RPC call proposed in #13943. Each client could register a blockheight that it needs to not be pruned, with some sort of client identifier. Then, as the client syncs, it can update it's keepheight value by passing along the new height along with its client identifier. The node will then only prune blocks below the minimum keepheight.

How would you deal with a faulty RPC client that never updated its "keepheight"? Would you require a re-register at some specified interval?

That could be an option, however may not be necessary. If there is an additional rpc call that can just list all of the registered keepheights, the maintainer of the node could evict one if disk space ever becomes an issue. The node could also emit warnings in the logs if one of the keepheights ever falls too far behind the chain tip.

Closing due to lack of momentum. Can re-open if this is something that picks up support in the future.