Bitcoin Forum

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?

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

SHHH....Don't talk about that.  No one is allowed!  Rule #1 of Bitcoin is that you don't talk about the blockchain size.  Rule #2 of Bitcoin...

Oh now its over 10 gb now, btw...  But I just broke rules there..

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

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.

A whole team? Do u know their names?

Everything is relative wont make to much difference.

Ya man, DOS was great... Windows and the internet ruined everything.

10 GB can be stored on a 2007 low-end Zune, so I see no issue with the blockchain size. If you can't hold it, either get some better software or use a lite client.

Disagree. Any software should aim at reducing resource requirements where technically feasible. And 10 GB is a lot for what is from most users viewpoint a simple tool for managing transactions.

All bitcoin users I know are unsatisfied with blockchain space requirements and download times. On the other hand the majority of them does not want to use lite clients as they prefer full control over verification.

Reducing the blockchain size and thereby improving performance of the reference client will clearly be a huge benefit.

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.

This is a whole bag of nonsense.

in 10 or 15 years, we will have 50 gb/ps connections, and the block chain will likely download in 15-20 minutes.

Care to explain your comment?  Or are you trolling with worthless comments?

I didn't say it was possible, just that it would be beneficial to truncate old transactions periodically.

50gb of 10 year old transactions on everyone's computers is nonsense.  

"offline archives" makes no sense: if I download the blockchain I want it all, otherwise I could just use a thin client.
the comment about the phones make no sense either: thinking about using a full client on a phone is just insane.

Hahahaaha

So true

+1

If people would expend 32 GB for a simple tool for entertaining oneself (https://en.wikipedia.org/wiki/Age_of_Conan%3A_Hyborian_Adventures), I find 10 GB for a revolutionary financial transmission technology perfectly acceptable.

Of course, I don't deny that reducing blockchain size would be useful. However, I do find it very low priority and believe the project would be better served with security, usability, and internationalization updates.

* Bandwidth throttling,

* Save a copy of wallet to ... (USB, /desktop/, ...)

Use a web wallet. Problem solved.

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

Nah, they've not been indexed yet.

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

How much smaller would the pruned blockchain be?

http://utxo.tumblr.com/

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).

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.

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

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. :)

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.

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.

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.

This post is full of win.

 :D

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  ;D

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

Life is like a fortress of trades.

:P

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.

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.

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.

I don't know much about namecoin, but could it be used for the certifications?

Probably.  You can embed a certificate fingerprint (http://dot-bit.org/Namespace:Domain_names_v2.0#TLS_support) in namecoin's database.

The problem is the client.  There is a whole big chain of trust that needs to be managed between the client validating the certificates, and the authority for them.

Also, note that namecoin is going to be absolutely terrible at mapping namespaces to real world entities.  If there is a big real world entity that you know about, odds are very good that someone else owns most variations on that entity's name and trademarks.

And then there is typo squatting/phishing.  We end up in a situation where users must be very carefully compare the namecoin token to be sure they are fetching the right fingerprint.  This is a rather modest improvement over carefully comparing the fingerprint itself.

PKI sucks, and key management in particular.  Anyone else remember the late 90s, when encryption was reclassified from "munition, not for export" to not-munition?  Real security depends not only on good math, but also on good practices.  Perhaps someone in the NSA realized that we had no hope of developing good practices, so they decided to let us distract ourselves with good math.

Bitcoin v.9 is great im looking forward to how it plays out overtime

Dont you guys agree with that?

Of course not: a web wallet would host only a *single* copy of the blockchain for all its users, not one for each of them.

Of course yes. They will need to double their storage every several month. Do not think that it will be for free.

I have visions of sysadmins frantically purchasing new drive after new drive to add to their servers, all sitting empty.

Hint: with the current block size limit, a 1 TB drive will die of old age long before it fills up in 2032 (at the soonest).

We've changed the default client recommendation on bitcoin.org to be MultiBit, so new users should be downloading that instead. MultiBit syncs the block chain in a few seconds for new users, because it's an SPV client. The security model is stronger than a web wallet and not quite as strong as Bitcoin-Qt, it's somewhere in the middle.

Basically - as long as the majority of mining power is honest, MultiBit is secure. Caveat: unconfirmed transactions when you have a malicious internet connection, then, you may see bogus unconfirmed transactions that are garbage and will never confirm.

"all private keys are kept encrypted on your local machine (or on a USB stick)"
http://www.multibit.org/features.html

"Faster to synchronize - usually a minute or so"

But how does it work?  described here:  https://bitcointalk.org/index.php?topic=252937.0

I wonder what else doubles every year... (http://encyclopedia2.thefreedictionary.com/Kryder%27s+Law)

If blockchain size doubles every half year, and hard drive density doubles every year, I wonder, who will finally win?..

When measuring exponential growth, average block size (https://blockchain.info/charts/avg-block-size?showDataPoints=false&show_header=true&daysAverageString=7&timespan=all&scale=1&address=) is more useful than total block size. Since 2011, average block size is doubling only once per year.

Its a pity that my disk does not know anything about average block size.

Sorry if I did not make my point clear. I'll elaborate.

We are talking about the sum of a geometric series. However, this sum is not strictly exponential. The formula is proportional to (1−qⁿ)/(1−q), where q is the growth factor in average block size and n is the number of blocks. When n is large, the formula can then be approximated as qⁿ⁻¹. When n is small, however, this approximation is not successful.

Consequently, to predict future block sizes, we must take into account the fact that the future approximation does not currently hold. A better prediction is to use the ratios of q itself, which is the growth factor in average block size.

Ah, just downloaded and poked the .wallet files in ~User\Library\Application Support\Multibit with the TextEdit stick. They aren't in clear text anymore. Cool.

Confirmed. Coin control.

Regardless the details upon which growth factor depends (you can't predict it precisely anyway), competition between blockchain size and hard drive densities is silly. Waste of resources. Bitcoin blockchain is just quick and dirty solution, and I hope, in the future, a crypto-coin will come out wich solves this problem in more elegant way.

Now I know how it works:
https://bitcointalk.org/index.php?topic=252937.msg2690447#msg2690447

And Schildbach is:
http://schildbach.de/

MultiBit by Jim Burton (lead developer) with Gary Rowe and Tim Molter (contributors), and Android "Bitcoin Wallet" by Andreas Schildbach, with both projects incorporating the innovative code from bitcoinj by Mike Hearn https://code.google.com/p/bitcoinj/

They're built using it, not inspired by it. bitcoinj is the module that handles all the communication with the Bitcoin network. The apps add a GUI on top.

Thank you.  I will fix it.  I was trying really hard to give everyone credit, and I still dicked it up.

TradeFortress is it true your Satoshi?

I like this feauture, thanks

I love this feature!