Quote from: Tigggger on July 13, 2017, 09:45:55 AM

Quote from: franky1 on July 13, 2017, 06:25:42 AM

Quote from: d5000 on July 12, 2017, 11:54:59 PM

the problem is the initial block download/verification (first sync) and the propagation and verification of new blocks.

the synchronisation is not a problem. the actual headache is that cores UI is not set up to function until synchronisation is complete.
as thats the real headache people gripe and moan about in regards to syncing
EG
no user balance or being able to spend until node has downloaded certain blocks that contain the users UTXO.
this can be fixed by having the UI function in Lite mode where it grabs a UTXO set first. or even just requests UTXO from peers of the keys the user owns. and then synchronisation becomes a background issue that can be done as and whenever the user pleases.

thus making a node spendably functional from the first hour

I currently have 3 nodes running and when the code for Segwit2x is released that will go up to 4. I have always run a node since I started but at the moment I want to make sure I am ready in case anything bad happens and that I will have a fully synced node running each type so that I can safeguard my bitcoins, probably a bit paranoid but better safe than sorry.

So anyway I feel the pain of that initial download/verify/sync having done more times than I can remember, and have wondered why it HAS to be done that way.

'New' nodes may not have any transactions of their own to download, and they may only want to run a pruned node, so surely it should be possible to do this in a backwards way similar to what you are suggesting, maybe with an option during install.

Do you have transactions to import ->
Yes -> Start from 0 as it works now (or like in your suggestion)
No ->
   Do you want store the full blockchain ->
   Yes -> Start from current block - x blocks (eg 2016 blocks), get the node up and running and usable then grab the previous blocks in the background (again like your suggestion)
   No -> Current block - x blocks (eg 2016) which then makes it a pruned node always holding just the previous x blocks.

This would surely help the number of nodes to grow ?

Looks pretty much bitcoins core is not really done to attract exponential growth at all. So how the hack this should scale at all ?

No industrial optimization allowed -> stay on small, nichy Rasp PIs

Or

Allow industrial competition, get rid of code bottlenecks -> Blocksize, Scaling and decentralization is NO ISSUE for all !

It will not be needed that any average Tigger (sorry, dont feel blamed, rather feel thanked getting it up to that actual stage ) runs 4 nodes at all - buy you some bitcoin .