<p>Pruned nodes don't have the ability to make a full index of all transactions in the chain, which makes implementation of tools like Lightning difficult or impossible. There's no risk particularly, a pruned node has the same security properties as a normal one, it just doesn't have historical transaction data necessarily. </p>

CC BY-SA 4.0
2018-12-22T02:27:37.803Z
There 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
CC BY-SA 4.0
2018-12-22T02:58:13.063Z
"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
CC BY-SA 4.0
2018-12-22T04:35:07.947Z
I was to mark this as accepted, but this has a downvote; I will wait for corrections.
sanket1729
CC BY-SA 4.0
2018-12-22T11:44:59.910Z
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
CC BY-SA 4.0
2018-12-22T11:45:33.683Z
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
CC BY-SA 4.0
2019-01-10T21:59:36.737Z
@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
CC BY-SA 4.0
2019-01-11T10:05:05.360Z
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
CC BY-SA 4.0
2018-12-21T22:12:12.003Z
2018-12-22T02:03:38.357Z
2018-12-22T02:03:38.357Z
Claris
<p>Most lightning implementations I came across don't officially support pruned full node. </p>

<ul>
<li>Why is pruned mode implementation a challenge?</li>
<li>What risk am I taking when I run lnd with pruned bitcoind?</li>
</ul>

<bitcoind><pruning><lightning-network-daemon><core-lightning>
What are the issues of running lightning daemon with pruning node?
sanket1729
# What are the issues of running lightning daemon with pruning node?

(Asked by: username_0 on 2018-12-21)

Most lightning implementations I came across don't officially support pruned full node.

* Why is pruned mode implementation a challenge?
* What risk am I taking when I run lnd with pruned bitcoind?

**Tags:** bitcoind, pruning, lightning-network-daemon, core-lightning


---

## 1 answers

### Answer by username_1 on 2018-12-21. Score: 1

Pruned nodes don't have the ability to make a full index of all transactions in the chain, which makes implementation of tools like Lightning difficult or impossible. There's no risk particularly, a pruned node has the same security properties as a normal one, it just doesn't have historical transaction data necessarily.

> **Comments:**
> **username_2**: There 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.  
> **username_0**: "Notice that currently pruned nodes are not supported and may result in lightningd being unable to synchronize with the blockchain." from c-lightning README.  
> **username_0**: I was to mark this as accepted, but this has a downvote; I will wait for corrections.  
> **username_3**: 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  
> **username_3**: 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 :-)  
> **username_4**: @username_3 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?  
> **username_3**: 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).  

---

