Topic: FACT CHECK: Bitcoin Blockchain will be 700GB in 4 Years - page 3. (Read 9321 times)

Bump, just because its better than my chart.

What will the next halving bring?

edits

(fucking hate mobile auto-correct sometimes)

[citation needed]

please, can you elaborate on this? do you have a link or something? I'd like to know what escapes validation.

I understand that things that it reads from disk are not validated, and only a few last blocks are verified at startup, but they were validated before they were written, so everything gets validated. Doesn't it?

According to Gregory Maxwell, even Core does not validate all transactions.

I would point out that this is totally counter to the concept of Bitcoin being a trustless currency, but The Devs^tm have spoken.

False. Blocks are already primarily full on average, thus there is no additional space to jump by 50-100% in terms of blockchain growth regardless of adoption. If you were talking about Segwit, which I'm sure that you're not, then it would be an entirely different story.

This has nothing to do with the subject. Go (signature) spam somewhere else.

They are usually based on outdated Bitcoin Core versions (most newer coins are as well). You can read about the change here.

I see, i'm used to bootstrapping old altcoins, didn't know this. thanks.

According to you current rate is 4% monthly so this 4% would definitely increase to 6 to 9% monthly because adoption of bitcoin is taking very fast now a days. All these 7 years from 2009 to 2016 Hutton was in dark but now only people are recognising its value so it's adoption will definitely affect in its monthly growth rate.

This has been obsolete with the introduction of faster-synchronization. in 0.10.0. It will be slowed than using the client.

Ignore that guy and his FUD, he doesn't know what he's talking about. Once Bitcoin moves away from ECDSA it should be quantum proof for the foreseeable future.

Why will bitcoin be gone? Won't there be a new way we can revive or keep it going? That worries me what you said now lol. So what will happen then? We just kind of got started.

Do you still need to validate blocks when you use a bootstrap?

No. Please do not post when you don't know what you're talking about. The bottleneck currently is not, and is likely not going to be the download speed.

You're assuming that the 8 nodes that you're connected to can provide you with a full speed download at all times for that speed. As mentioned above, the bottleneck is going to be the validation time.

you must still be on dial up or something

700GB can be downloaded in less than a day on 4G Connection (80mb)

it would only take 9 hours to download 700GB today on a 200mb connection (fibre)
(which are available in certain developing countries already for $50/month)

you might want to look at:
http://www.download-time.com/

700GB in 4 years will be nothing in most countries

ill just leave this here

THIS
It's linear, not exponential


you can also fit a quadratic function to your graph
but it's capped by a linear function
segwit may change the slope, but still linear

my prediction: your 5% will start to decrease asymptotically towards 0%

nope. generally the switch of the signatures allow 1.6x-2x capacity depending on number of sigs of a multisig address or multi-input vs single input.
this is done by splitting the tx data from the signatures
1mb base (tx data) 3mb witness(signatures)=4mb total potential weight

the "witness" part (3mb) which brings cores total weight to 4m wont be utilised fully straight away, but will be used later to allow new features such as confidential payment codes where the weight area can store this payment code as extra data outside the base block and inside the witness area.

thus, lets say we have ~2500 tx a block today for 1mb. (traditional transactions)
the average scaling proposed is 4500tx if everyone was to move funds and use only segwit style transactions..
4500tx:~1.8mb weight (tx data=1mb base... signatures=~0.8mb witness = ~1.8mb weight used)

but that leave the witness area capacity with (2.2mb) spare for other later uses like scrambling sensitive data for privacy.(confidential payment codes)
making about 4500tx+CFP:4mb if fully utilising the weight (base and witness area) for other such features.

however if we were to accept 4mb of data was no longer "bandwidth heavy" now that core have stopped the bandwidth heavy doomsday debate we could have had 5000tx:2mb(traditional).. or 10,000tx:4mb(traditional)

but instead the best average we can hope for is
4500tx:2mb in 2017 and 4500tx+CPF:4mb in 2018

unless we go for 2mb base 2mb witness=4mb weight - yes this means segwit still gets to be used for all the segwit fanboys
meaning we can have 9000tx using segwit but not having confidential payment codes

It won't grow exponentially people..

My 4% to 5% guestimate was based off some data.

If segwit gets accepted by miners, no reason why it shouldn't, we'll have to wait for 1-3 months to see evidence of the impact on blockchain growth.

Any predictions?  For example, will the growth rate remain at 4-5% or move up to 5-8%, or something else?

Correct. The expected 1.7 MB is based on the current real world usage (primarily P2SH). r/btc recently tried to spread FUD that for 1.7MB worth of transactions, Segwit requires 4 MB of data (which is wrong on so many levels).

Not just a 'little tighter'. Multisignature size after Schnorr will be trivial in comparison to the current one, we are talking about much smaller size or the same size as a 1-of-1 (this depends on whether you want to know who signed messages).

Kind-of, but it's the *gold standard* of digital signing algorithms.

You should definitely keep historical data, so that we can compare with 2017 (with 'after-Segwit data').

Since posting the OP, the blockchain has gone from



~81GB, to ~88GB

So, a little over my monthly growth prediction, but it grew by 5% between end of Sept and end of Oct.

Ah, the ratio between the tx block and the signature block has to reflect the average signature size, hence all the "block weight" language used to describe the signature block structure. So the ratio gets a little tighter if we drop ECDSA for Schnorr sigs. Cool, the transaction data should get prioritised in the ratio if it can be done right (and Schnorr has other benefits over ECDSA also). Is the Schnorr scheme not relatively new though?

If you take a look at some testnet blockchain explorers, you will encounter a few different types of blocks. In general, the heavier the multisignature usage is, the closer will the *block size* reach 4 MB. However, a whole different story will be *told* if Bitcoin Core upgrades to Schnorr signatures (where multisignature style transactions would be of similar or equal size to standard transactions).