Sjors Provoost

That's indeed what I ended up doing, rather tedious, and adding a dependency on internal data structures. https://github.com/blockchain/libwally-swift/pull/45/commits/eac080bddd1c21a1ba41c2064cbfeb062bfcda8d?file-filters%5B%5D=.md&file-filters%5B%5D=.swift#diff-dd5b685bc72957e5736a7a36ebcea752f6c6e49bd4f5a0792b46e6f4cecb9658R20

Is it correct to say that a node that's manually pruned to block 504500 ( `.when_lightning_became_cool`) and not pruned after that, is safe to use?

Shouldn't `when_lightning_became_cool` be enforced by `gossipd`? As in, it would simply ignore such gossip.

Pruning down to block 504499 means storing only 20 GB at the moment, 80 GB should last until the end of the year, at which point hopefully the problem is...

Payee mode is probably also too limited this way. It’s not great privacy and cost wise to close all channels everytime a shop needs to move their funds. Partial blindness...

That could cause the node to run out of disk space if c-lightning never comes back. Perhaps a second parameter could specify the max additional storage allowed before pruning kicks...

TIL https://github.com/bitcoin/bitcoin/pull/10794, which introduces `requestblocks`, lets a pruned node fetch arbitrary historical block data.

Only for channels that were created before your lightning node (new channels are tracked normally). And only for channels that you're considering using for a specific outgoing payment. See [mailinglist](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001386.html)...

> storage requirement fixed Keep in mind that SegWit hasn't been active for two years yet and blocks are nowhere near capacity, so you should keep a (2x?) margin. Though...

A rather different approach is suggested by @TheBlueMatt [here](https://github.com/bitcoin/bitcoin/issues/12651): > I think this use-case is significantly more simply implemented with gettxoutproof/verifytxoutproof/decoderawtransaction. If you've already discovered from somewhere that you want...