Is anybody working on pruning on the main client?

[piotr_n]

Yeah, give us more reasons why implementing a chain compression isn't important at all - and thus will take you so much time as I said it would...
Plus, we need more patronizing from the bitcoin elite, because they are the ones who know how to write a bitcoin software, while we obviously know nothing about it.

SPV clients is the future of bitcoin and the key to the solution of its ever known scalability issues.
After every node (except the ones run by Google) switches to SPV mode everything will be just perfect and all the problems will be gone once and for all

[Sukrim]

"Normal" users will NOT be happy with a fully pruned chain state, as this only contains their current balances and 0 history.

I would love to see fater developments too, but as you can see, even if you pay someone a few 10k USD (as happened in the thread I linked) they will still rather ask for more than producing workable code. If you want to see development work done on pruning, please read the thread I linked and "donate" to his funding goal, develop yourself or hire someone else/better to do this.

Complaining about slow development speed will only slow this spped down further, as I am sure a few devs will waste their time reading this thread in the hopes that someone stepped up for the challenge or to answer the question initially asked and instead will be presented with your rants.

[piotr_n]

What is on the agenda here, forcing most of the nodes to switch into SPV mode - this is an indirect attack on the decentralization, which is an extremely important property of this currency and a major factor in its market value.

You can pretend having a good intentions, but your objective is clearly hostile.

[Sukrim]

...I'm outta here.

If you don't understand why fully pruned nodes with cryptographic proof in the chain headers are much worse than SPV (since they won't need to rely on full history nodes) are MUCH worse for the network centralization wise, you can go on and spread your rants and complaints to yourself.

Edit:
P.S.:

Yet before the blockchain grows up to 1TB of data.

Approximate point in time this will happen, unless there is a hard fork:
In the 2030s. You will need to replace your HDDs (which live about 5 years) 3-4 times until then.

[piotr_n]

That is why I do not defend purging and never have.

I do think though that it is very important to solve the scalability issues, likely through some method of the chain's compression...
Yet before the blockchain grows up to 1TB of data.
55-60 GB of transaction data per year is not a problem for you - well, that's great man, but for me it seems a bit extreme, to say the least.

SPV clients are not a solution, since they don't contribute to the network - they only look at it.

[piotr_n]

Approximate point in time this will happen, unless there is a hard fork:
In the 2030s. You will need to replace your HDDs (which live about 5 years) 3-4 times until then.

You obviously missed the fact that lifting the max block size is also on the agenda...

Plus imagine how much time it will take to download the blockchain, starting from block #1 in the 2030s.
That's of course assuming that we will keep relying on the bitcoin elite to solve our problems.
Which we obviously won't, because we are not crazy to delegate such an important tasks to such a lame and corrupt developement team

[grv]

Sorry, but if you want to run Bitcoin-QT on a local machine, it will be easily able to handle the few GB (current computer games are MUCH larger) of space and traffic. Otherwise you can also use prominently featured lighter clients like Electrum or Multibit.

Please tell me exactly why me reasoning that having a block chain that contains 4 years(!) of binary transaction data and still is half the size of a current computer game (random google, yes I know it's XBox One...: http://callofduty.digitalwarfare247.com/2013/11/call-of-duty-ghosts-is-a-39gb-install-on-xbox-one/) is "arrogant and narrow minded"?!

Currently the block size limit is ~1 MB, which gives a constant hard cap of about 55-60 GB of transaction data per year. This can be stored on a USB drive that you can get for 30 USD with free shipping (again random google, I am sure you can get it cheaper too: http://www.amazon.com/SanDisk-Cruzer-Flash-Drive-SDCZ36-064G-AFFP/dp/B007JR5304).

How the hell is this amount of storage going to drive away "most of the average people"?

i've worked with average people (as in not technically skilled about computers) for decades at local university so i got to know how they think and the limits of their understanding (as in interest in learning something they don't have to/want't to or need to).
anyway, a game which they will delete after a few weeks and replace with another. not so for the blockchain
you really don't see the problem with such a huge amount of space required? how long do you think it will take to sync a 100gig blockchain. weeks? what about 1tera, a month?
so first time user will have to wait way LONGER than a bank wire transfer. so much for the "transaction speed".

so on one hand you have the idea of decentralization, and on the other ease of the use and efficiency. what is the middleground? some form of distributed blockchain?

[MoonShadow]

What is on the agenda here, forcing most of the nodes to switch into SPV mode - this is an indirect attack on the decentralization, which is an extremely important property of this currency and a major factor in its market value.

You can pretend having a good intentions, but your objective is clearly hostile.

Bitcoin was never intended to run on every user's machine.  Absolute decentralization isn't a requirement, and it's long been expected that Bitcoin will scale as much as it needs to scale, and will naturally centralize as much as it needs to do accomplish that scaling.  That said, SPV mode & pruning are both among the early plans to reduce the need for this as much as is reasonable.  There is no doubt that the whole blockchain will persist somewhere, and that this is more likely to be done by an institution for many reasons.