1There is no reason that lightning should need access to a non-pruned node, and AFAIK c-lightning doesn't. Regardless, any requirement for non-pruning is an implementation specific limitation. – G. Maxwell – 2018-12-22T02:27:37.803

"Notice that currently pruned nodes are not supported and may result in lightningd being unable to synchronize with the blockchain." from c-lightning README. – sanket1729 – 2018-12-22T02:58:13.063

I was to mark this as accepted, but this has a downvote; I will wait for corrections. – sanket1729 – 2018-12-22T04:35:07.947

c-lightning technically works with pruned nodes, the problem however is that if the node prunes the blocks before c-lightning was able to process them (for example by letting bitcoind run and lightningd is off for a long time), then c-lightning will not be able to catch up with the blockchain. If you can ensure that c-lightning is also running together with bitcoind, I see no problem with it and we have a number of users that are running it like this – cdecker – 2018-12-22T11:44:59.910

The support mentioned in the readme is just to say that we don't want masses of people spamming the issue tracker with pruned node issues :-) – cdecker – 2018-12-22T11:45:33.683

@cdecker are you saying that bitcoind has to be unpruned when first starting lightningd (i.e., bringing a lightning node online for the first time) and only then can bitcoind be told to prune? – jhfrontz – 2019-01-10T21:59:36.737

Not exactly, lightningd will start syncing at the height that bitcoind is at the time of the first start (it'll not go back to the genesis block). It is only problematic if bitcoind is also syncing (since it'll outrun lightningd which will eventually end up in the pruned section of the blockchain) or ir lightningd is offline while bitcoind is making progress (also leaving lightningd in the pruned section and unable to catch up). – cdecker – 2019-01-11T10:05:05.360