rich1.0npub1du3xh5wgds32a5fweqkd9k45kh30wl7kv2kyu8ugz9c2ztdg00tqqvyg93https://nostr.ae/npub1du3xh5wgds32a5fweqkd9k45kh30wl7kv2kyu8ugz9c2ztdg00tqqvyg93njumphttps://nostr.ae📅 Original date posted:2015-08-09 📝 Original message:On Saturday 8. August 2015 19.05.29 Alex Morcos via bitcoin-dev wrote: > I agree > There are a lot of difficult technical problems introduced by insufficient > block space that are best addressed now. I agree problems for space restrictions should be solved, and the sooner the better. What your statement has as a side-effect is that we will run into problems when the moment of insufficient block space comes *this* year instead of in 5 years. I can practically guarantee that no proper solutions will be deployed in time for natural growth of usage to reach always 1Mb full blocks. Having several more years to make such solutions will be very healthy. > As well as problems that scale > will exacerbate like bootstrapping that we should develop solutions for > first. Notice that many people here have tried but have been unable to find a relation between max-blocksize and full node-count. Also, there are pretty good solutions already, like a bootstrap torrent and the headers first. In the upcoming release the actual CPU load should also get better making the actual download much much faster than the 0.9 release. Or, in other words, these problems have been solved in a large part already, and more is underway. I don't expect them to be showstoppers when a the network finally allows bigger than 1Mb blocks. Natural growth has shown that blocks won't jump in size significantly in one month anyway. So this scenario still has 6 months or so. -- Thomas Zander