Topic: Bitcoin roadmap (Read 12755 times)

some says that bitcoin has a roadmap and whitepapers. i didnt know if its real either. all i know is that ico's only have a roadmap,whitepapers and other important details  to be able for people to track their progress.

Do not forget the https://lightning.network , I also  would love to see some (approximately) dates
Regards
Onedb

It will also help to optimize the file writing, because it seems kind of suspicious for the program to be using the hard drive so intensely. Trojan? Spyware? is what many people will be thinking. Not to mention, that writing 65 000 times to the same file isn't so great for HD reliability

If I am correct, Bitcoin *can* work with only the last block. If I'm not, correct me!
But this is insecure because if that last block isn't verified, it might be bogus!
Every block is signed with the previous block. (Or something like that. I'm not an expert on the algorithm.)
So, if you don't have block 10, you can't verify if 11 is valid, you first need 10 for that, and to verify 10, you need 9, and so on.

When Bitcoin starts, it begins downloading the genesis block, and verifying it, and continues down the line checking all blocks and saving them. It's like a linked chain!
Eventually every block in existence has been checked and saved, and right now that's like 27 megabytes.
The block downloading mechanism isn't that fast. If I am correct it writes the whole file to the harddrive everytime -- or maybe just one sector -- when it gets a new block, so it'll write 65000 times to your hard drive... not exactly what you call 'nice'.

I have a solution.

Anyhow, does Bitcoin need all the blocks to function? Yes
Can we hardcode a block into Bitcoin to save time? Sorta, we don't want to download just from that hardcoded block on. Not saving every block makes the network insecure and starts a dependence on older clients which have saved all the blocks!
So we cant save space? No, not by not saving the blocks, that's insecure. We can hardcode a block into Bitcoin, and initially let Bitcoin not download from the genesis block up to the hardcoded block.
Bitcoin will then download only from the hardcoded block up to the current block, and after that the client can be used. (To generate/transfer coins/etc)
So we have a he chain up until the verified block, we make the network insecure and start a dependence on the older clients which have saved all the blocks!

By asking for that same block, and verifying it's local hardcoded copy, the client can just skip downloading the first blocks up to the hardcoded block temporarily.
Then after those blocks have been downloaded, and ofcourse, verified from the hardcoded block on, Bitcoin will start downloading from the genesis block up to the hardcoded block and verify those.
Thus enabling Bitcoin to be used without waiting that long, yet still preserving the genesis block up until the hardcoded block.

And when the network grows larger, we can just move the hardcoded block to the current block when the release is compiled.
This seems to me like a great solution to the problem of having to wait a long time.

This might be insecure, but only so far.
The hardcoded block's data will be hardcoded and compared against the received block.

You've made me think of another question to ask: will all new instances of BitCoin clients always have to download all existing blocks? Won't that eventually mean that as the number of blocks increases, the time taken to download the blocks and the space to store it will be enormous.

I'm presuming I've got this wrong, as the developpers are rather cleverer than me, but can someone explain the flaw in my thinking?

You can use the 'addnode' flag on the command line to add a node, and it will generally go faster, I heard so from people, worth a shot!

What I would like to see is lower time to get started – currently, it takes several hours just to download all the blocks, which amount to few megabytes of data.

Or does it take so long because my PC has to verify all the blocks?

Is there a roadmap in place for future development of Bitcoin? Let's discuss the features we believe would improve adoption and usability of the client:

* Seperation of Bitcoin API into a standalone embeddable module

I believe this is important so that third parties can port Bitcoin to different platforms, with different UIs, etc.... look at how many platforms we now have for Bittorrent, and the functionality is also embedded into different applications.

* Flat file format for coins

Coins should be exportable into a flat file format, which will be readable by the core API and thus re-importable to other clients. This flat file format should be encrypted natively (though people can choose to embed it in another encryption format, thereby providing double encryption).

* Full security audit of Bitcoin

This will be needed in order to provide a measure of trust.

* Increased anonymity/privacy features

Simply integrating with Tor/I2P, like BitTorrent programs allow, should help. Experts in these domains could point out simple optimizations that could be done and would not slow down the network significantly.

* Protocol obfuscation/encryption

This is a simple manner of survivability, in case ISPs or other agencies attempt to monitor, filter, or block Bitcoin traffic.

I believe these are the most important features. Other features could be implemented by third parties as they embed the Bitcoin module into their apps. Witness the vast proliferation of Bittorrent clients, each with their own sets of features on top of the base Bittorrent featureset.

Other things that will help to drive adoption:

* Increased exchange methods. It is not that easy to get Bitcoins right now!
* Increased payment sites. This is a manner of advertising Bitcoin and getting people to accept it. Again, if Bitcoin was a standard module that people could just drop into their web apps, this would be much easier.

Satoshi, what do you think about development bounties and the like? I wouldn't mind donating a few resources to help get these things done more quickly. I would code myself, but my C++ is rather rusty