Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

2018-06-14 Thread Brian Lockhart via bitcoin-dev
Resolved -> RTFM Worked like a champ, first try. Thanks! Wish I had thought to look into that sooner! My c-lightning node’s resource footprint is even smaller now. Unfairly small. And now that I’ve unexpectedly regained ~180 GB worth of free SSD space from not having that extra full node, I’m

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

2018-06-13 Thread Christian Decker via bitcoin-dev
Brian Lockhart writes: > In the interest of avoiding running multiple bitcoind full nodes - is there > a method to allow a Lightning node to point to / access a separate > already-existing node, vs. requiring it to have its own dedicated local > instance of bitcoind running? > > I.e. if I already

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

2018-06-13 Thread Brian Lockhart via bitcoin-dev
Somewhat related question - In the interest of avoiding running multiple bitcoind full nodes - is there a method to allow a Lightning node to point to / access a separate already-existing node, vs. requiring it to have its own dedicated local instance of bitcoind running? I.e. if I already have

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

2018-06-13 Thread Christian Decker via bitcoin-dev
Kulpreet Singh via bitcoin-dev writes: > But if I understand correctly, lightning nodes need to check if a > counterparty is broadcasting an old channel state and in response > broadcast a penalty/justice transaction. Does that mean lightning > nodes only need to watch for transactions that come

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

2018-06-13 Thread Kulpreet Singh via bitcoin-dev
Apologies for a noob question. But if I understand correctly, lightning nodes need to check if a counterparty is broadcasting an old channel state and in response broadcast a penalty/justice transaction. Does that mean lightning nodes only need to watch for transactions that come after the

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

2018-05-10 Thread Patrick Shirkey via bitcoin-dev
> On 3/17/18, someone posted on the Lightning-dev list, "Can I try > Lightning without running a fully-fledged bitcoin block chain? (Yubin > Ruan)."  The inquirer was asking because he didn't have much space to > store the entire blockchain on his laptop. > > I replied: > > "Developers, > > On

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

2018-05-10 Thread ZmnSCPxj via bitcoin-dev
Good morning karl and Segue, Specifically for c-lightning, we are not yet rated for pruned bitcoind use, although if you installed and started running bitcoind before installing the lightningd, caught up to the chain, and then installed lightningd and set things up so that bitcoind will get

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

2018-05-10 Thread Jim Posen via bitcoin-dev
That is a good observation that most of the historical data does not need to be kept around. I believe what you are suggested is already implemented, however. Bitcoin Core can operate in a pruned mode, where the bulk of the historical block data is discarded and only the current UTXO set (and a

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

2018-05-10 Thread アルム カールヨハン via bitcoin-dev
He can use pruning to only store the last X MB of the blockchain. It will store the UTXO set though, which is a couple of GBs. In total, a pruned node with pruning set to 1000 MB ends up using 4.5 GB currently, but it varies slightly due to the # of UTXOs in existence. On Thu, May 10, 2018 at

[bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

2018-05-09 Thread Segue via bitcoin-dev
On 3/17/18, someone posted on the Lightning-dev list, "Can I try Lightning without running a fully-fledged bitcoin block chain? (Yubin Ruan)."  The inquirer was asking because he didn't have much space to store the entire blockchain on his laptop. I replied: "Developers, On THIS note and