new feature - bitcoin v.9

[Eri]

Maybe pruning will be implemented as a 1.0 feature (pruning, that thing that makes the blockchain allot smaller)

[bitcoinator]

Maybe pruning will be implemented as a 1.0 feature (pruning, that thing that makes the blockchain allot smaller)

How much smaller would the pruned blockchain be?

[readonlyaccess]

There is a team of people actively working on the scalability issue by introducing indexing.

A whole team? Do u know their names?

http://utxo.tumblr.com/

[AliceWonder]

I don't have a problem with the blockchain size, but I do think the documentation needs to be altered to suggest a lite client to newbies who generally don't need to have the blockchain.

I've had friends sitting there for days trying to get the blockchain, some have given up, it particularly seems to be a problem on Mac OS X. I wish I had a mac so I could try and figure out what the issue is.

Me running Linux - took about a day (beginning of June or end of May).

[DoomDumas]

a lot of great new feature, im impressed and hope this addition of code will be very clean, secure and efficient as it as always be until now.  Gratz to de Dev team, keep up your very good work.. We how so much to you all !

edit : I dont have a problem with the blockchain size, just the download time that bother me..  There should be a full torrent download, automatically installed in the client folder, for the first 200 000 block at least !  I would dedicate upload bandwith to such an effort.

[TippingPoint]

I don't have a problem with the blockchain size, but I do think the documentation needs to be altered to suggest a lite client to newbies who generally don't need to have the blockchain.

I agree.  And after they have some experience, they may want to run with the big dogs.

[kwukduck]

Boohoo we really need altcoins, bitcoin is dead!
The 10GB blockchain is killing my 12TB diskspace! I can't download anything anymore because of this stupid blockchain files!

[antimattercrusader]

Boohoo we really need altcoins, bitcoin is dead!
The 10GB blockchain is killing my 12TB diskspace! I can't download anything anymore because of this stupid blockchain files!

Lol, that made my day.

[AliceWonder]

Boohoo we really need altcoins, bitcoin is dead!
The 10GB blockchain is killing my 12TB diskspace! I can't download anything anymore because of this stupid blockchain files!

Well, to be fair, most people don't have 12TB. Especially if they are running laptops with an SSD.

[kwukduck]

Boohoo we really need altcoins, bitcoin is dead!
The 10GB blockchain is killing my 12TB diskspace! I can't download anything anymore because of this stupid blockchain files!

Well, to be fair, most people don't have 12TB. Especially if they are running laptops with an SSD.

Even my phone has 64gb storage... Yes, of course not everybody has storage capacity, the point is, 10gb is nothing (some of my blue-ray movies are bigger), and even if the size keeps increasing rapidly, storage capacity is getting cheaper every day and is growing rapidly too. Same goes for bandwith bandwith.

I really don't see a problem here, but of course it would be elegant if we had a 'solution'  to this perceived problem. Dev's are working on that afaik so i don't think there's need for another 20 topics on the issue.

[Pentium100]

Boohoo we really need altcoins, bitcoin is dead!
The 10GB blockchain is killing my 12TB diskspace! I can't download anything anymore because of this stupid blockchain files!

The problem is not the space requirements (for all I care the blockchain could be 100GB - I have a 300mbps connection and could spare a 120GB hard drive), but that it takes forever to download because of all the CPU, memory and disk I/O requirements. Last time it took me almost 24 hours to download 6 weeks of blocks and during all that time the CPUs were pegged at 100%.

I would very much like to run the client in a virtual machine (to not have to run additional server and save money by paying less for power), but the initial download is very hard on disk I/O and the client leaks memory in addition to pegging the CPU. However, as it is now, I have to keep the bitcoin server on in case I want to send/receive some coins this week. And if I turn it off, I have to remember to turn it back on a few days before I want to send coins or confirm that I received them.

The blockchain could be backed up and placed on a FTP or HTTP server once a week or so. Then I could just download the file from there, start the client and it would need to download less than a week of blocks. That would speed things up considerably.

Another problem is that while there is a console client and a GUI client, there is no frontend for the console client. I could run the console client on a Raspberry Pi (and skip the initial download by copying the blockchain from my current server) and keep it on all the time (it does not use a lot of power), but then I would have no GUI frontend.

[giszmo]

guys, you are off topic.

on topic: I'm surprised by the features. It is progress and the dev team certainly has a reason to go this way but to me it feels rushed after a rushed 0.8.2 that also got many people by surprise. I don't see why a CA should be used in Bitcoin. Is this a protocol extension? The return-address certainly is an extension but I don't see why this linking of transactions should be in the block-chain. A service could have an api to receive signed messages with return addresses for certain transactions (if you receive a transaction with id X, please send return to Y. Please confirm this signing with the key of address 1dice...). Will these payment requests be public? Will transactions reference these requests? Where can I read more details? Why not sign with keys? Where can I read what plans the devs have to integrate next?

Are these changes pull requests now? Are they well tested on the testnet?

All in all I would just want more and kind of earlier info. Everybody knows about pruning but this gets delayed over and over it seams while some surprise-features pop up with next releases.

[kjj]

guys, you are off topic.

on topic: I'm surprised by the features. It is progress and the dev team certainly has a reason to go this way but to me it feels rushed after a rushed 0.8.2 that also got many people by surprise. I don't see why a CA should be used in Bitcoin. Is this a protocol extension? The return-address certainly is an extension but I don't see why this linking of transactions should be in the block-chain. A service could have an api to receive signed messages with return addresses for certain transactions (if you receive a transaction with id X, please send return to Y. Please confirm this signing with the key of address 1dice...). Will these payment requests be public? Will transactions reference these requests? Where can I read more details? Why not sign with keys? Where can I read what plans the devs have to integrate next?

Are these changes pull requests now? Are they well tested on the testnet?

All in all I would just want more and kind of earlier info. Everybody knows about pruning but this gets delayed over and over it seams while some surprise-features pop up with next releases.

*sigh*

You need some way to authenticate the payment blocks.  Despite their many, many flaws, the SSL CA system is still by far the best way we have to do that.  You can still use self-signed certificates if you want to.  Personally, I'm hoping that the growing public awareness of CA abuse will spur people to finally develop a better system.

No, this is not a protocol extension.  The payment system exists outside of the bitcoin network.

The information in the payment protocol (such as the return address) is not included in the block.

The payment protocol is the API for signed messages containing metadata about transactions.

The requests will only be public if one side or the other publishes them.

Pruning has not been delayed "over and over" in favor of trivialities.  There are prerequisites that needed to be followed.  The Ultra-prune branch in git, for example, didn't actually do pruning, it was a collection of work that needed to be done before pruning could be implemented.

[drrussellshane]

Everything is relative.  The blockchain size is very small compared to the number of stars in the universe, and the download time is very short compared to the time it takes to grow an oak tree from an acorn.

This post is full of win.

 

[yvv]

10 GB block chain size is an issue.  We are only 4 years into the use of bitcoin with relatively low amount of transactions.  Fast forward 10-15 years once bitcoin is main stream, and block size definitely could become a major issue.  It would be nice if a "new" genesis block could be created every 5 years or so.  All the past transactions could be rolled up into an offline archive.  The block chain size also becomes an issue for mobile (phones) devices.  Nobody wants to download a 25-50 GB file before they can use their phone wallet.

Take into account that blockchain size doubled since early this year. If it continues to grow at same rate, in early 2017 it will exceed 1TB, in the middle of 2018 10TB, by the middle of 2020 100TB, etc.

No, this is not an issue at all  

[yvv]

Figure out a way for late adopters to not have to download +8gb of data when they first start Bitcoin-qt.

Use a web wallet. Problem solved.

Not for web wallet. With exponentially growing blockchain size, it will become a problem for them very soon.
 

[drrussellshane]

Figure out a way for late adopters to not have to download +8gb of data when they first start Bitcoin-qt.

Use a web wallet. Problem solved.

Yes, there are tradeoffs, but everything in life is about tradeoffs.

Life is like a fortress of trades.

[hodginsa]

I understand that we will have faster internet, more storage, and faster computers in the future. But the issue is, if I want to get my non computer savvy family on board, that issue will have to be dealt with. Not everyone is going to want to download the huge blockchain, and if you can see, it takes awhile now, I think the rate of expansion will match the rate of tech improvements making it relatively the same amount of time to download in the future. Web wallets are not a solution, I wouldn't trust them with all my money.

[TippingPoint]

I am using Bitcoin Wallet by Schildbach on my Android tablet.  It is fast and cool, although I still don't know how it works.

[countryfree]

http://thegenesisblock.com/significant-merchant-improvements-planned-for-bitcoin-v0-9/

seems like innovation is continuing. what do people think? what should be added to v1?

There are some nice ideas, but I think the developers should focus on speed. Getting a transaction confirmed fast would help a lot in business. With different technology, Twitter is an impressive example of how to spread short pieces of data over a huge network at an incredible pace.