Topic: 1mb is too big - page 3. (Read 3404 times)

The question will be whether or not we will have to power to computer that much in transactions on a regular basis!  That is a lot and because of the difficulty levels now, normal joe's can not just mine BTC, so what are we looking like in the future.

I'm guessing certain Core members have large positions in alts.

No wonder they want to keep strangling BTC.

Greed.

I don't like topics about block size. It's smarter to talk about free space within each block. On an average computer, most people would say you need to keep at least 15% free space on your hard disk so that you work on files without hiccup. It's the same thing with BTC. If we're close to max capacity, things will be less smooth. It may even stall at some point and we don't want to see that.

Yes, essentially.

Your question contains an assumption: that downloading is the only thing that's happening, or that it's the only thing that takes time. It's not.

The signatures of the transactions need checking. That involves finding and reading the blocks where the tx's were ALL minted from (which is not an inconsiderable amount of disk I/O), and then checking that each tx signature satisfies a cryptographic proof that it really originated from those blocks. And Bitcoin has to do that for every transaction in every block since genesis.

The early blocks (1-170,000) barely contain any tx data at all, as no-one was sending much BTC around. Once we get to around 2011 (>170,000), the tx rate ramps up exponentially, and so the complexity of the initial sync'ing job goes up at an even higher rate.

Who are you to prevent me from making a 1.01 MB transaction if the block size allows it? I see a bad precedence here.

Flat rate is usually based on fair usage. You should read the small print.

None have succeeded with that, nor do they have many users. Not that this is a bad thing.

They are both related. You lose decentralization, you will also likely lose values such as that. I disagree with the last part, that was not *the only promise*.

There isn't even a single viable candidate yet.

Yes, at a 1mb transaction limit, it would scale linearly from today's worst case and still allow any transaction that is currently valid.

If you pay for a data rate and they don't deliver that data rate they have breached your contract.

Bitcoin has fallen to 80% of the cryptocurrency market.  Transactions throughput has stalled.  Other coins are working hard on massive throughput and are continuing to grow.

The promise of bitcoin was not that everyone can run a node.  The promise was that no single entity could control the issuance of money.  Bitcoin can only meet this promise it it can scale enough to be useful as one of the primary means of international exchange.  The good news is that if it doesn't, some other coin will.

What do you mean by "restrict transactions to 1 MB"? Restrict the maximum size of an individual transaction to 1 MB?

I highly suspected that they are testing normal 10 MB blocks, which is obviously the wrong way to test stuff. Otherwise, that statement wouldn't hold ground. At 10 MB, with quadratic validation time, you could reproduce a block that requires a ridiculous amount of time to process.

The problem isn't the speed, the problem is the amount that you spend. Even at 1mbit/s, you can have 40-80 connections (again, source: my node). However, do you really think that you wouldn't be throttled down very soon considering that they'd probably label this as "not fair use"?

If you restrict transactions to 1mb, then you can scale linearly from the current worst case.

Bitcoin unlimited is running a testnet with 10mb blocks and they aren't even close to straining decent desktop hardware.

Bandwidth usage can be high, but 20mbit/second is pretty easy to come by.  If you have less, you can serve fewer nodes but still provide more to the network than you consume.

Does that mean validating 10 blocks (each 0.2 MB) takes less time than validating 2 blocks (each 1 MB)? That would explain it, although I don't get why this would be different.
I only have 4 GB RAM so much more dbcache won't work.

Probably I've had this on my mind for a while, and reading about the 20 MB blocks triggered it.

I'm not sure how you don't know the obvious answer to that question: Because the blocks are larger. Just because the block size limit has been at 1 MB for years, that does not mean that the blocks were actually 1 MB in size. Blocks prior to 2015 and 2016 were usually quite smaller. Note: Downloading these blocks at 2 MB/s isn't the bottleneck, but validating them is. You can speed this up if you add a high "dbcache" setting (e.g. 4-8 GB).

It shouldn't stop if it isn't doing anything. Relying on HDD noise is a bad way of testing whether it's actually doing something. If the CPU load is low, then the bottleneck is the IOPS of the HDD.

Again: Validation time. You could copy over the whole blockchain and do a reindex to check. In other words, reindex builds the blockchain index and chain state from scratch (no downloading). You're going to notice that it takes a lot of time, especially on weak hardware such as yours.

---

Hint: Something like this should probably be discussed in a separate thread.

Does anyone know why current blocks take so much longer to download in Bitcoin Core than old blocks? As far I as know the increased difficulty is only related to mining and has nothing to with checking downloaded blocks.

Example: When I start a fresh installation of Bitcoin Core, it starts downloading the blockchain. It quickly goes through the first years with small blocks, then after that it's downloading with more than 2 MB/s continuously. That means at least 2 blocks per second (say 90 seconds to download 1 day's worth of blocks). But when it gets closer to the current date, it slows down.
Now when I start Bitcoin Core, it downloads fast for a bit, then stops, continues a bit later again, and then downloading stops entirely for a long time. CPU load is low, hard drive I can't hear (and I have no indicator LED). My question is: why is it so slow? Why can't it continue to download 2 MB/s so I can update 3 days in 5 minutes?

This also happens on a trimmed version of the blockchain, so it can't be caused by Bitcoin Core checking all transactions on disk. The only thing that also gets bigger in the trimmed version, is the chainstate directory (now 1.6 GB). Could that be what slows it down?

As another test, on my old Atom laptop, it updates 3 weeks blockchain in 2 calendar days. To come back to the statement I quoted: if blocks would be 20 times larger, and I extrapolate this, my old Atom couldn't keep up anymore. And if this gets worse in the future, it could become a limitation for faster hardware too.

While I've typed all this, Bitcoin Core running on my i3 still says "3 days behind", the same as when I started typing. Network activity has slowed down to just a few kB/s "background" level. What is it doing?

What is this about? Is this a reference to the Blockchain?

No, I'm fairly certain that you've pulled that out of thin air. Exactly where, when and how did you benchmark validation time for a 20 MB block? Quadratic scaling induces problems with malicious 2 MB blocks, now imagine the implications on 10x of that.

You are forgetting several things in your point of view: 1) Syncing from scratch; 2) Bandwidth. Sure, you could argue that you'd need only download 20 MB worth of data on average every 10 minutes. However, this does not apply for full nodes, but full clients. A node, doing an average of 1 mbit/s at the current block size of 1 MB, will spend around 300 GB of data in 30 days (source: My own node).

Yeah, it is subjective.  My desktop could easily handle 20 mb blocks, and it isn't anywhere near top of the line.  Sure, in 5 years I'd need more disk space, but I could also buy enough disk for 20 years at that rate for less than $600.  In 5 years when I actually need it, that storage will likely be even cheaper.  The CPU, RAM, and network connectivity I have today can already handle it.

Did you draw this by yourself?It`s nice.

Or i guess it`s created before 20 years when 1MB was too big.

For me 1TB isn`t enough.

No, not "everyone" has to run one. We're already pass that point IMO. However, you should be able to run a node without it costing you a lot of money (this is subjective I know) if you want any kind of decentralization.

Just because Satoshi had a view regarding something, that doesn't mean that they were right. I disagree with 'running a full node to being a business activity'. It's not like the node count isn't slowly going down due to the ever increasing resource cost required to run one.

So we should believe in Ver's words, the same person that vouched for Mt.Gox solvency?

Remember, BTC is now being ran by these types:


https://www.reddit.com/r/btc/comments/52l541/we_should_not_change_btc_to_accommodate_more/

Why does everyone need to run a full node?  See section 8 of the bitcoin white paper.  Even Satoshi viewed full node operation as a business activity.  If you didn't sign up for Satoshi's vision, what exactly did you sign up for?  It sounds like you're rather have a toy than a tool for stopping banks from leaching from hardworking citizens via government bailouts.  That is first and foremost the mission of bitcoin.  Just look at the timing of its creation and the message encoded in the Genesis block.

Just common sense. When the computer is struggling to run the node then it's not viable. If you are not able to work with your computer while you have your core wallet opened, then it's not viable since you would need a secondary computer.

Guys, you're missing the point.

Somewhere in an alternate universe Greg Maxwell exists as a talking dog.