Topic: Why do you need to download 7 years of chain block (Read 9128 times)

I am assuming you are talking about the first method (in bold). Maybe I missed something in the debate but whats the connection with the block size and storing headers?

I think, if you can download 7 years of chain block, you should do it to support the the decentralized system. Do not fall into the trap of collective irresponsibility! Well, if you cannot download that much data, you still could use the client and do transactions or find an alternative, lightweight client. In the long term, we are advised to find a solution for the big data problem in-before bitcoin network starts a centralization pattern.

the size is not a problem, but it takes a long time to download because you need to verify every single transaction and that takes a lot of processing power.

Normally I can download 40 gigabyte files in minutes, but downloading and verifying the blockchain takes weeks, if not longer.

I don't think it's necessary at all.

Here is a quote from the original whitepaper:


I just think this is just being shoved under the carpet because it probably conflicts with the devs idea to keep the 1MB blocksize limit in place.

don't be a wuss and take it all
all 40 gigs
you can use lightweight clients like mycellium and save yourself the trouble of downloading and syncing
or you can use web based wallets
core wallets are for the hardcore bitcoin enthusiasts,I don't use core since 2014 and have no remorse.

I download blockchain bitcoin already 1 month ... I think, blockchain bitcoin will be his gravedigger ... The more people will use it - the longer download and will take up more space on disks

I am very much surprised with the low amount of download speed from Australia. I have read in news in the internet it is considered a developed country. In my country Italy it is very easy to get an ADSL which downloads with 20 MBPS and we can download the whole blockchain in just one day at the worse.

However if you don't want to download the full blockchain, you can use SPV wallets like electrum or Multibit.
Here are their websites:
www.electrum.org
www.multibit.org

Noob questions, but on the topic to SPV wallets. Is there a way of importing an old wallet (from 2009) into Eletrum with a "wallet.dat" file?

Thanks in advance!

In Australia most of our ADSL lines cap out at around 300kbps download - so if you want to download the blockchain then you better start 2 and a half days earlier than you actually want it. I wonder if eventually we will move to a centralised archive of transactions up to a certain date and 'reset' the local blockchain (similar to what happens with a web wallet now). As long as you trust the centralised archiver then it could prove to be convenient, albeit at the introduction of additional risk of corruption.

It answered my question of y download the block chain

If you see a newly generated block, that means "k" state snapshots in the past (for different heights) are stored by the network, and the guarantee is pretty strong. On delegation, to reach line 15 in the RollerPoW function with a new input (so anything changed in with fixed )  you need to recalculate a ticket so you can't fix a_t and outsourcing of ticket calculation doesn't make any sense.

Quote from: gmaxwell on September 04, 2016, 07:53:43 PM

The other is that you begin nodes from a state snapshot, not at the tip, but at some point somewhat back. This is also taught in in the citations I provided above.  This also does not prove that the state is correct, in fact it provides no evidence at all that the state is correct except under a strong assumption.

Which assumption?

Quote from: gmaxwell on September 04, 2016, 07:53:43 PM

Perhaps it would be revealing to answer a question:  You are a new node joining the network. I am part of an attacking consortium which has, for several months, had a super majority hashpower at my disposal.  Can I cause you to accept a chain extending the chain from no further than a few months back, otherwise compatible with a 'honest chain' (if it existed)-- meaning containing all the same transactions and ownership except as mentioned-- where I instead have a million extra BTC reassigned from the earliest blocks?

If "a super majority hashpower" is committed to adversarial behaviour, we got common prefix property (and chain quality also) from the GKL model broken. Light verification is also broken in this case(it assumes common prefix property being hold, see Theorem 2). Full verification is also broken though. Even more, how can you define a desirable bootstrapping procedure outcome if common prefix property isn't held? If it is held, bootstrapping outcome could be simply defined like "a new node is getting chain C such as set (C |_| chains of honest participants) satisfies common prefix property". I'm going to update the paper with a definition like that.

I did not miss this.   But unless I am misunderstanding you,  you appear to be conflating two orthogonal changes.

One is the change to the POW which requires the miner to show possession of state snapshot data.  This does nothing to assure users that the data is correct.  It ~may~ increase the odds there are multiple copies of it (though unless I misunderstand it-- your design is trivially delegatable so long as the miners are willing to trust the party storing the data until their coins mature, which users of mining pools already do almost ubiquitously).

The other is that you begin nodes from a state snapshot, not at the tip, but at some point somewhat back. This is also taught in in the citations I provided above.  This also does not prove that the state is correct, in fact it provides no evidence at all that the state is correct except under a strong assumption.

Instead, participants hope that the state is correct without checking under a strong assumption that the majority hashpower would not extend a chain with invalid state updates. This is the SPV security assumption.

It is different and weaker than the normal Bitcoin behavior, trusting a majority hashpower for the soundness of state updates and not merely their sequencing. In practice it is not sufficient to simply take such a strong assumption and not question it's validity-- normally the SPV hashpower assumption is justified by the widespread and economically significant use of full nodes which will not be deceived by dishonest miners; but with full nodes also making a SPV assumption for blocks away from the tip, this argument becomes circular.

The SPV assumption is especially concerning because we have discovered that miners have begun bypassing validation themselves in order to mitigate the negative effects of larger amounts of transaction data on propagation. State sampling proof of work has been argued as a potential improvement for this particular issue, but proposals so far have worsened the generation of progress in the mining function (as the last miner to create a block has a state update advantage) and they still leave plenty of opportunity to optimize by shortcutting the parts of validation that the state updates do not expose.


Perhaps it would be revealing to answer a question:  You are a new node joining the network. I am part of an attacking consortium which has, for several months, had a super majority hashpower at my disposal.  Can I cause you to accept a chain extending the chain from no further than a few months back, otherwise compatible with a 'honest chain' (if it existed)-- meaning containing all the same transactions and ownership except as mentioned-- where I instead have a million extra BTC reassigned from the earliest blocks?

It really hurts to download the 7 years of blockchain on slow and turtle-speed internet connections like in my country. However as an alternative you can use Multibit-HD wallet which is very much compact ans useful since id does not need to download the entire 20GB+ blockchain.

Otherwise the need for the entire block ledger is there since that what is needed to understand the distribution of coins and for new transactions.

I know that Bitcoin Core can run in Prune Mode, effectively cutting disk space you will need for storing blockchain data.
But you will still need to download whole blockchain before that. Is there even remote possibility that we won't need to download whole blockchain in the future by using some sort of 'pruning'?

Yes, this is possible. Your neighbor's client will read the blockchain and start where it left off.

You don't have to unless you download the main client. It supports the network to be a node, and you can even self-mine from your wallet (with little to no effect, though.)

At least some clients/miners need to maintain the entire blockchain at all times to reach consensus. Every single transaction matters because it affects the entire history.

I must say that I do not mine and that I do not know much about mining, but I have a question:
Can't the blockchain be imported from a usb medium?
I mean, if I download it and put it on a usb stick (if that is possible), can't I give it to my neighbour so that he does not have to download the blockchain?

Even for a fullnode, Bitcoin protocol does not enforce nodes to store (any number) of full blocks, so if a new node is able to download blocks since genesis that is the artifact of altruistic behaviour. RC works under stronger assumptions about rationality of network participants. Please note nodes in RC could save more full blocks than required by the protocol, even from genesis (as in Bitcoin), but that's not really needed (as well as in Bitcoin).

I understand "why" we have to download it. But oh man, it's awful! I wish I knew I was in for eighty gigs about three years ago, when I got into Armory.

Back then it was only around 30 gigs, doable in a day. There has got to be an easier way. Let's hope that when the blockchain size hits something like 20 T, internet services will also have kept up and evolved at the same rate.

I think Rollerchain (RC) is similar in motivation to SPV but different under the hood.

(If I understood correctly, haven't spent too much time on it)

Assume round 0 is "now" , -1 is last block, -2 the one before that, etc.

Let U_i be UTXO set at round i

SPV stores Delta(U_{-n}, U_{-n+1}), Delta(U_{-n+1}, U_{-n+2}) .. Delta(U_{-1}, U_0)

RC stores: (U_{-n}, Delta(U_{-n}, U_{-n+1}), Delta(U_{-n+1}, U_{-n+2}) .. Delta(U_{-1}, U_0))

Thus, SPV is equivalent (at least in storage complexity) with RC having the additional initial state.
In RC, once a new block (delta) is mined, the state U_{-n} is updated to U_{-n+1} and U_{-n} is discarded.

The difference I think is that SPV does not enforce nodes to store n blocks and its more or less a risk if every node prunes their chain to just 10 blocks (acting "rationally").

RC claims to enforce within the protocol itself that the n blocks be stored.