Is anybody working on pruning on the main client? - page 2.

Peter Todd

legendary

Activity: 1120

Merit: 1150

Quote from: piotr_n on December 07, 2013, 09:08:55 AM

though, more likely scenario is that within the next 8 people will forget about the original bitcoin dev team and start making/using their own mods.
it's actually already happening - has happened while you were busy with designing black and red lists during a conference with US financial "authorities", otherwise known as the core of the wold's financial regime

Mike != the dev team.

Anyway, Litecoin contracted me to implement pruning, although there's no particular timeline on that contract; it depends on sipa's headers-first which has its own set of issues.

piotr_n

legendary

Activity: 2053

Merit: 1354

aka tonikt

Quote from: gmaxwell on December 06, 2013, 10:31:22 PM

Quote from: Sukrim on December 06, 2013, 09:37:30 PM

, but it is not really exposed out of fear that there might be too many people actually doing it which would hurt chain distribution.

Thats not _quite_ accurate. The P2P protocol has no way to communicate which nodes have which block other than a binary state for "full node or not" which implies all the block. To have pruning we first must change the p2p protocol to communicate nodes that are full nodes but can only serve recent blocks (+some named subset of the history, most likely). There are also a bunch of other minor details like refusing to serve blocks it doesn't have instead of just crashing on the request.

right.
changing the p2p protocol - that sounds like a really tough one.
seems like at least 10 years of work, for you guys.
but the good thing is that you have already spent at least the last two years on analyzing the problem, so there is a decent chance that it will get done within the next eight...

though, more likely scenario is that within the next 8 people will forget about the original bitcoin dev team and start making/using their own mods.
it's actually already happening - has happened while you were busy with designing black and red lists during a conference with US financial "authorities", otherwise known as the core of the wold's financial regime

nomailing

full member

Activity: 126

Merit: 100

Quote from: Sukrim on December 06, 2013, 10:51:28 PM

Well, a pruned node would anyways report as non-full node, right?

A first step could have been to have pruned nodes that store no history at all, then start on "hybrid" nodes, that store some history for the next iteration. Why the approach the other way round?

I guess, because then you might loose a lot of full nodes completely in a very short time frame and then build them up again slowly. So you would have to bridge a time window of instability and untested conditions.
Therefore the other way around is better, where you try to slowly shift from full-nodes and slightly reduce their history step-by-step.

Sukrim

legendary

Activity: 2618

Merit: 1006

Well, a pruned node would anyways report as non-full node, right?

A first step could have been to have pruned nodes that store no history at all, then start on "hybrid" nodes, that store some history for the next iteration. Why the approach the other way round?

gmaxwell

staff

Activity: 4200

Merit: 8441

Quote from: Sukrim on December 06, 2013, 09:37:30 PM

, but it is not really exposed out of fear that there might be too many people actually doing it which would hurt chain distribution.

Thats not _quite_ accurate. The P2P protocol has no way to communicate which nodes have which block other than a binary state for "full node or not" which implies all the block. To have pruning we first must change the p2p protocol to communicate nodes that are full nodes but can only serve recent blocks (+some named subset of the history, most likely). There are also a bunch of other minor details like refusing to serve blocks it doesn't have instead of just crashing on the request.

MoonShadow

legendary

Activity: 1708

Merit: 1007

Quote from: Sukrim on December 06, 2013, 09:37:30 PM

Other than that supposedly bitcoind already can prune, but it is not really exposed out of fear that there might be too many people actually doing it which would hurt chain distribution.

Can you point me to more details about this? I'm having trouble finding it with the search functions.

Sukrim

legendary

Activity: 2618

Merit: 1006

The last I heard about active pruning was https://bitcointalksearch.org/topic/fundraising-finish-ultimate-blockchain-compression-204283

Other than that supposedly bitcoind already can prune, but it is not really exposed out of fear that there might be too many people actually doing it which would hurt chain distribution. Also header-first sync might allow for some nice features (e.g. keep the last N blocks + a random sample of the older ones, up to size X). I don't know about progress there though, in general I would just advise to invest the 2 USD or whatever a few dozen GB of HDD space costs these days and just store all blocks.

If you have such an old PC that a few GB are of concern, you might want to think of switching out harddisks anyways, especially when storing wallet files on there...

MoonShadow

legendary

Activity: 1708

Merit: 1007

Just curious, because I've been getting a lot more questions about the resident size of the blockchain.

Topic: Is anybody working on pruning on the main client? - page 2. (Read 2054 times)