Topic: new feature - bitcoin v.9 - page 2. (Read 4526 times)

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

Probably.  You can embed a certificate fingerprint 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.

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

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 am using Bitcoin Wallet by Schildbach on my Android tablet.  It is fast and cool, although I still don't know how it works.

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.

Life is like a fortress of trades.

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

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  

This post is full of win.

 

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

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.

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.

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.

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

Lol, that made my day.

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!

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

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