Hacker News Reader

Comment by gtrubetskoy | Hacker News Reader

8MB block means the block chain grows by 1,207,959,552 (~1GB) per day, or ~365GB per year. This means that now not everyone has the internet connection or the disk space to keep a copy of the block chain, and more control is in the hands of the miners.

I understand the reason for a larger block - it seems like it's pure profit for the miners (should we just refer to it as greed?), but I do not understand the objection to SegWit which is essential for lightning to work.

I am fairly convinced at this point that off-chain transactions as described in the lightning docs [1] is the future. The block chain cannot possibly support all the transactions, there could be millions per second if micropayments do take off, and that will most likely happen via the channels as described in the lightning docs.

[1] https://github.com/lightningnetwork/lightning-rfc/blob/maste...

Edit: If you're not familiar with lightning, you should read up on it. The gist of it (my understanding, I am not exactly a bitcoin expert) is that if I trust someone, there is no need to announce to the whole world that I just gave my kids ice cream money, it's between me and them. And it's instant. The blockchain is used only as last resort, when one of the parties does not cooperate as as agreed.

View on HN

I always thought that was a weak argument. There are currently 8403 nodes online if I believe https://bitnodes.21.co/, that's not exactly impressive. If a big miner wanted to take over the majority of the nodes they could probably afford to just spawn spawn 10 thousand nodes.

Not that it will do them a lot of good, what matters most is what the exchanges and other important economic entities handling bitcoins consider "the real bitcoin", having a majority of nodes won't do much.

There's simply not enough incentives for Bitcoin users to spawn a node so most people prefer to use a light wallet.

Furthermore ~400GB per year is not particularly insane, you can get a 6TB drive for less than $200 and that'll be enough to store more than 15 years worth of blockchain.

As for bandwidth it amounts to less than 14kB/s on average.

>there could be millions per second if micropayments do take off, and that will most likely happen via the channels as described in the lightning docs

Maybe, but I'm a bit surprised that so many people believe that LN will be successful when we have so little data on how it'll actually work. But I'm going to repeat myself, I already explained my concerns here: https://news.ycombinator.com/item?id=14759965 (with some insightful replies).

In particular I can't really imagine how LN could reach a Visa-level number of transactions without having a few mega "nexus nodes" concentrating most of the open LN channels. That would give those nodes some power as they could decide who they pair with (which channels they open) which would be a big blow to the decentralized nature of Bitcoin.

The idea that every bitcoin user would each end up having a handful of channels open and we'd keep routing around the graph (with all the balancing issues it involves) to pay everything seems rather optimistic and aligns poorly with real-world incentives.

> There's simply not enough incentives for Bitcoin users to spawn a node so most people prefer to use a light wallet.

Bitcoin users are important economic entities.

There is no distinction between a "consumer" and a "business" in Bitcoin. Everyone is a user. Everyone sends and receives payments.

Users don't have to run a full node to use it though. I'd bet that most users just use a 3rd party web wallet (such as Coinbase), and thus are contributing nothing to the network in terms of decentralization.

In fact there's a happy middle ground: you can run Electrum or similar. These are "SPV" (simplified payment verification) clients. They sync only a small amount of blockchain data, relying on proof-of-work to confirm the data's validity, instead of validating the entire chain from the genesis block.

That way you still get to keep control of your keys, and you get a little control over the consensus rules you think are valid, but you don't have to sync the entire chain.

This is what most users are likely doing.

Highly doubt that's "most" users, considering Coinbase's numbers

Most Coinbase users will be exchanging on Coinbase and then transferring to their SPV wallet.

If that's not the case, then, well... that's what they should be doing.

Just because Coinbase has X amount of customers doesn't mean that many people are using Coinbase as a wallet. I'm a Coinbase customer but I don't use Coinbase as a wallet.

It's definitely not what people are doing. Even as Mt Gox showed, people will just leave it where it's convenient. And for a lot of common users, they probably ARE a lot better off with their coins existing as a row in Coinbase's MongoDB database than as a file on their PC.

And I say this as someone that dislikes Coinbase and was burned by them (one day they seized all my coins until I verified ID on login, then erased my bank account connections and refused to delete my PII that I only provided to withdraw my coins in the first place.)

Welcome to the world of financial regulations.

Seems suspicious that, despite having validated my bank account and despite me making no more transactions with it, they demanded more ID Just to get the product I'd already purchased.

That's not true. Someone who buys and uses bitcoin is giving it value as a currency. As the network effect rises, the prices rises, which increases the reward that miners get.

The CPU and bandwidth resources are trivial. Torrent traffic from a decade ago is many orders of magnitude more bandwidth than what bitcoin or even all currencies combined are. It is literally a non-issue.

They're all economic entities. They're not all equally important.

What coinbase and other exchanges consider to be the "true" bitcoin matters a whole lot more than what some guy who just installed a bitcoin node on his raspberry pi thinks is the true bitcoin.

In the end bitcoin is worth what people are willing to pay for it. Even if you have the majority of the nodes if nobody accepts your forked bitcoin then it's worthless.

> In particular I can't really imagine how LN could reach a Visa-level number of transactions without having a few mega "nexus nodes"

I think that's a valid point, but we won't know how it will play out until we actually get there. It seems to me that the "large block" crowd is of the "let's not go there" opinion, but I think they're resisting the inevitable.

> I think that's a valid point, but we won't know how it will play out

That sounds like a terrible plan. Let it play out on Litecoin or some other toy blockchain.

The large block crowd wants the easiest most straight forward way of scaling now. Which isn't to say other solutions aren't welcomed. But it's strange that the Core team has made it an either or.

It's weird how in certain forums there seems to be overwhelming support for blockstream - but everyone I meet in real life doesn't have that same enthusiasm.

Well some of the big blockers are against anything that'd prevent ASICBoost (which is a really fun/neat thing, look up the details if you haven't.) That does cast some suspicion on the purity of their motives. But I think the slightly-larger blocksize (8MB) for now is quite reasonable, and the lack of even 2MB size is really indefensible.

I don't know much about ASICBoost - but if the reason for changing the PoW algo is because of the US patent system.. then let the US patent system catch up, not the other way around. Bitcoin wasn't designed so that American miners have an equal opportunity.. Who comes up with these ideas

Parents aside, I understand AsicBoost encourages empty blocks.

>I think that's a valid point, but we won't know how it will play out until we actually get there.

That seems to be the consensus and that's my main issue with the entire ordeal. We're talking about a $40 billion market cap currency, not a bittorent tracker. Maybe it would be worth taking a bit more time to run some simulations and figure out the long term plan?

IMO looking mostly from the outside (I'm not heavily invested in any cryptocurrency) it would've been more reasonable to bump the block size a little bit in the short term (maybe 2 or 4MB) to let the current architecture carry its weight for a few more months or even years and take that time to come up with something better than "back of the envelope calculations", to cite what I read in some LN papers.

So block even slightly larger blocks just because "we'll find a better way eventually"? Why not both?

8000 is a misleading number. I do all of my transactions through a full node but my ports are not forwarded and also I only have uptime for about 1/3 of the year (most months it is offline because I'm not using it. I only run it to refill my mobile wallet or make big transactions).

When the lightning network is up and running you can bet that I'll be using my full node for that too.

120GB of disk space is a big hit. My drive is a 500GB SSD. Bitcoin runs a lot slower on an HDD. But mostly people saying "oh it's only $5 a month" I feel aren't actually running nodes. It's inconvenient already, the sizes are already hurting adoption, and making the chain bigger is definitely going to make that situation worse.

I run a full bitcoin node on a USB3 HDD formatted in fat32 so I understand where you're coming from but it's really not that bad. Sure, when I boot it up after a few weeks offline it takes a little while to resync but so what? If I want to check something in a hurry I can use electrum or some website.

And once it's actually synchronized HDD or SSD doesn't matter much in my experience.

I don't think it's really a factor in adoption, most users don't feel the need to run a node already. People running nodes are enthusiasts first and foremost.

> most users don't feel the need to run a node already.

That's a big part of the issue. Already people prefer to run lite clients for convenience. There are heavy systemic risks that get worse and worse as the number of full nodes decrease. Back room deals become a lot easier for those who do run full nodes, because there aren't enough people running full nodes to prevent unfavorable network changes.

One you have synced your node, an HDD isn't a big deal but if you only run your node every few weeks or months you have thousands of blocks to sync each time. Then it's a pain, and SSDs are nicer. (This is my personal situation). I typically only boot my node if I intend to spend or receive coins, the sync time is already frustrating to me on an SSD and i7.

You don't want an ecosystem where only enthusiasts are verifying transactions. That's abusable, and if it forms a significant part of the economy it absolutely will be abused.

>You don't want an ecosystem where only enthusiasts are verifying transactions How is that now? Who are the non-enthusiasts that are preventing abuse by running full nodes?

For $20 a month someone could easily run a large-block full node and that price will only come down.

Not if you keep doubling the blocksize every time blocks fill up.

Also, would you pay $20/mo for a credit card? That's a big expense to participate in a financial system.

Going to 2, 4 or 8MB doesn't mean other things can't be looked at. It doesn't mean we end up with 256MB blocks. It's a cheap, simple extension for the time being.

How many independent nodes do we need to ensure it keeps working?

>There are heavy systemic risks that get worse and worse as the number of full nodes decrease.

It's true but as I pointed out in a sibling comment those risks are pretty slim as long as it's highly unlikely that all node runners could be colluding. It takes only one "uncorrupted" node to raise the alarm publicly, then anybody can spawn a node and check for themselves if they want.

>You don't want an ecosystem where only enthusiasts are verifying transactions. That's abusable, and if it forms a significant part of the economy it absolutely will be abused.

Okay but that's the way bitcoin works, with or without SegWit, with or without big blocks. There are not enough incentives to run a full node already. I don't think that will change unless you manage to create an incentive somehow.

It takes 1 hour to create 10 thousand nodes and it's not particularly expensive.

What can you make against bitcoin with that?

Bear in mind that 8000 is the number of nodes accepting connections. There are likely many more nodes connected to the network that are not listening. I base this on the fact that by default each node will attempt to maintain 8 outbound connections, so if each node accepted connections then on average they would each have a total of 16 connections.

However, in my experience any node accepting incoming connections will have many more than the additional 8 incoming connections we might expect. I throttle total connections at 64, but unthrottled I've seen it go over 100, admittedly after a few days of uptime.

> I always thought that was a weak argument. There are currently 8403 nodes online if I believe https://bitnodes.21.co/, that's not exactly impressive. If a big miner wanted to take over the majority of the nodes they could probably afford to just spawn spawn 10 thousand nodes.

Simply spawning 10 thousand nodes would not allow someone to take over the network in any sense.

That's exactly my point, yes. I often see people talking about the dangers of not having enough nodes but I think it's wildly overblown.

In practice as long as you have at least a few thousand nodes run by a variety of uncooperating users around the globe it should be enough to handle all the transactions and raise an alarm if anybody attempts something foul. The amount of coordination required to carry an attack by taking over the node network seems rather implausible.

For one thing you'd have to convince all the big exchanges and the miners to play along and then you'd have to hope that none of the people running the thousand of nodes would see the fork and raise the alarm publicly.

It might however make it easier to run "transaction malleability" attacks however but that's an other issue altogether and ought to be fixed in the short term.

> Furthermore ~400GB per year is not particularly insane, you can get a 6TB drive for less than $200 and that'll be enough to store more than 15 years worth of blockchain.

> As for bandwidth it amounts to less than 14kB/s on average.

Fourteen kilobytes a second is quite an understatement of the bandwidth needed to operate a bitcoin full node. Remember, nodes don't just download the chain: they also relay unconfirmed transactions and blocks to other nodes, which increases bandwidth requirements by a few orders of magnitude.

When I ran a full node a while back it was eating a couple of TB a month. Nowadays that blocks are full I suspect that it's quite a bit more than that.

You don't need to do any of this to secure the network though, it's all about "witnessing" what is the valid blockchain. You could write a dumb node that doesn't deal with unconfirmed transactions and only receive new blocks without relaying them at all. You'd still be able to detect a fork. You could even save some storage by only keeping unspent outputs from old blocks once verified.

Anyway, that's not even my main point. I just thing that I think this particular problem is overblown and used as a bogeyman by the opposing party. Not that "big blockers" are without blame, there are insane conspiracy theories on both side and even in between.

Hacker news is basically one of the only places where I've seen people being able to discuss these issues on a technical level without going full "the illuminati freemason bankers are trying to destroy bitcoin".

> You don't need to do any of this to secure the network though.

Not doing those things actually weakens the network. If most users operated a node like the one you described, there would be several negative effects on the overall network's health:

* It would take longer to relay transactions: full nodes would be less interconnected and there will be more "hops" between any two nodes. This in itself can cause many problems: it gives miners an incentive to centralize geographically (latency increases orphan rate) and can make a 51% attack slightly easier.

* The network will become more vulnerable to DoS attacks, because only nodes that relay transactions need to be targeted.

* Full nodes will have even higher bandwith requirements, because they will have to relay transactions to more nodes (that don't relay in turn), like a torrent with many leechers.

It's kind of like how the development of popcorn time is bad for the health of torrent networks (not the same though, different reasons).

> Anyway, that's not even my main point. I just thing that I think this particular problem is overblown and used as a bogeyman by the opposing party. Not that "big blockers" are without blame, there are insane conspiracy theories on both side and even in between.

I get it, but I don't think this problem is overblown.

>Not doing those things actually weakens the network.

It's true but it's not exactly in the same category. I was mainly considering attacks that would attempt to mess with the ledger, not a denial of service. DoSes are a problem of course, but it's transient and can be fixed "in hindsight" if it actually becomes an issue. Successfully tampering with the blockchain on the other hand would be a massive shitfest and non-trivial to fix.

I'm not really worried about the number of nodes becoming insufficient to relay the transactions because clearly people who are invested in bitcoin have all kinds of incentives to keep it running. That means that big exchanges and "whales" could easily invest a few dollars a month to run a full node on a high bandwidth VPS. Keeping Bitcoin usable would actually be a good incentive to run full nodes if that ever became a problem. If Bitcoin really keeps growing eventually banks, big companies and governments will want to run nodes and I presume they won't host them on a raspberry pi connected to a 56k landline.

On the other hand if your internet connection is too crappy to support 8MB blocks (14kB/s, remember?), I can't really imagine that it'll do a lot of good as a backbone for the bitcoin network. If anything you'll end up eating up bandwidth from external nodes as they forward you the blocks and transactions while not really contributing much yourself.

400 GB a year is notably faster than the average expansion of storage space. The growth of the block chain should ideally be limited to the average yearly increase in storage space on an average PC.

I currently run a full node since I have a gigabit connection but I will definitely stop if I need to increase storage space by that much. The current growth rate is maybe a tenth of that.

You also need to keep in mind that most residential usage limits are around 400 gigabytes per month. After this change, within a year the vast majority of people will not be able to run nodes outside a datacenter.

Within a few years when the blockchain is multiple terabytes it will be nearly impossible to download on a residential connection due to size and especially usage limits.

8MB is the maximum size possible for full blocks. BCC supports 2-8MB maximums. the 400GB stat is kind of like calculating how much gas you would use in a year assuming 8000RPM 24/7.

Also disk usage arguments still apply to SegWit. For instance: see this 3.7MB block on the test network, containing 468 transactions.

https://testnet.smartbit.com.au/block/00000000000016a805a7c5...

so if we're extrapolating from worst case scenarios, that's 658GB per year!

There might be a misunderstanding here. Capacity does not increase with the number of nodes. The only thing the number of nodes tell you is the amount of users who participate without trusting a third party. This is literally the invention behind Bitcoin. A company that deploys a thousand nodes does absolutely nothing for the network. An end user who deploys just one, and transacts with it, has real value.

Discussions around block size always include someone obsessed with storage, and that argument can go both ways. But storage is the least interesting aspect. Increased transactions per second means increased validations per second, which has a number of implications including increased latency in the peer to peer network. This affects mining protocols, orphan rates, mempool size, throttling algorithms etc. There are several interesting aspects, and storage is very far down the list.

A lot of work has been done for the past few years to improve that situation, look at the new crypto library for a few concrete examples. This kind of work is what led the developers behind segwit to provide for a quadrupled block size. I am not familiar enough with the details to have an opinion if that is somehow an optimal block size, but that's where we are now that segwit locks in.

I don't know what it is about block size that makes everyone and their mother so desperate for an opinion about it. People who have no clue about the underlying protocol or the various scaling properties of the involved algorithms pull a number out of the air and somehow that's their opinion of the matter. There are probably very interesting things to discuss here but it's completely drowned in noise of one single constant.

>There might be a misunderstanding here. Capacity does not increase with the number of nodes. The only thing the number of nodes tell you is the amount of users who participate without trusting a third party. This is literally the invention behind Bitcoin. A company that deploys a thousand nodes does absolutely nothing for the network. An end user who deploys just one, and transacts with it, has real value.

I completely agree, my point is that even with full 8MB nodes the barrier of entry is not much higher than it is today with 1MB node. Or to put it an other way I don't think we'd have 10 times more nodes if block size was at 100kB. I postulate that the main barrier of entry right not is simply bothering to actually set up a node.

At least in the "first world" the average joe has the resources available to run a full 8MB node without having to starve himself, both in terms of bandwidth[0] and storage[1]. So while there's some discussion to be had about what constitutes a safe amount of nodes online (Taek has some interesting points about that elsewhere in this thread) I still think it's pretty irrelevant in this blocksize debate.

>But storage is the least interesting aspect. Increased transactions per second means increased validations per second, which has a number of implications including increased latency in the peer to peer network. This affects mining protocols, orphan rates, mempool size, throttling algorithms etc. There are several interesting aspects, and storage is very far down the list.

That's a very interesting point and something I hadn't really thought about. I'm surprised though, given that nowadays the rule of thumb is "wait for 5 confirmations before accepting a transfer" it seems to me that the latency between the moment I issue a transaction to the network and the moment it's "mined" into a block is not that significant? I mean, at a rate of 8MB every 10 minutes you have the time to do a lot of crypto work on the nodes...

[0] https://www.statista.com/statistics/204952/average-internet-... [1] https://www.newegg.com/Desktop-Internal-Hard-Drives/SubCateg...

> Furthermore ~400GB per year is not particularly insane, you can get a 6TB drive for less than $200 and that'll be enough to store more than 15 years worth of blockchain.

Not everyone has access to such resources. You and I do, but many people run their lives on PCs with 32GB EMMC soldered to the motherboard, mobile devices, netbooks, public school computers with limited network-based storage, and internet connections that can barely allow a couple gigabytes per month. If a technology is not inclusive of the median hardware possessed by that (large) community, it will not gain traction beyond hackers with like us.

Also, the vast majority of people I know do not use desktop computers. Lugging around a 6TB external drive just to deal with payments, and then dealing with backing up that drive, is not exactly a good sell.

Those people already can't run bitcoin then, you need more than 100GB of storage currently (I think closer to 160GB now? I don't remember). Good luck running that on your smartphone.

So the question is: amongst the people running full nodes today, how many wouldn't be able to cope with 8MB blocks?

Also note that 8MB is the max size and blocks could be smaller, I don't expect that 8MB blocks would get fill up in the short term.

"8MB block means the block chain grows by 1,207,959,552 (~1GB) per day, or ~365GB per year. This means that now not everyone has the internet connection or the disk space to keep a copy of the block chain"

No. You provide no stats, no costs, to justify why 8MB is prohibitive while 1MB is fine. In reality 8MB blocks remain easily affordable. The limit where it starts being quite costly for an individual to run a full node is around 100MB:

https://news.ycombinator.com/item?id=14825934

And by the time we get to 100MB, computing, networking, storage technology will have improved and let us go even further.

> I understand the reason for a larger block - it seems like it's pure profit for the miners (should we just refer to it as greed?)

It should mean lower transaction fees for users, but more transactions are possible so the miners make it up on volume. Win-win.

> I am fairly convinced at this point that off-chain transactions as described in the lightning docs [1] is the future. The block chain cannot possibly support all the transactions, there could be millions per second if micropayments do take off, and that will most likely happen via the channels as described in the lightning docs.

If you trust your counterparty you wouldn't be using bitcoin in the first place. SegWit/lightning seems to undermine most of the point of bitcoin; certainly moving to transactions happening off-chain would be a radical change and it's not clear it would preserve bitcoin's positives (e.g. decentralization). Whereas increasing the block size is a simple, well-understood change.

> This means that now not everyone has the internet connection or the disk space to keep a copy of the block chain, and more control is in the hands of the miners.

Isn't this inevitable? Once demand of anything increases beyond a certain threshold, individuals can no longer supply enough of that thing to satisfy that demand, because they are overwhelmed by the costs of logistics, storage, maintenance and so on.

In the case of bitcoin, I imagine that soon you'll need to have dedicated machines for this task. Not a lot of people can afford to have one - or several, for redundancy - machines to do it.

Hence, the "power" - like in anything else - is in the hands of those that are willing to make a significant investment to keep things running. The payoff for them is that they can profit from providing this service. If I understand correctly, this comes in the form of transaction fees.

Or did you think that bitcoin could rise to the level of, say, Visa or Paypal on the backs of volunteers? Bitcoin isn't even "mainstream" yet, and the network is already buckling.

I think this outcome was more than predictable.

> I do not understand the objection to SegWit which is essential for lightning to work.

Let's talk about the realities of Lightning for a minute. Lightning is an interesting technology solution to scaling transactions and settling on the blockchain. But realize that there are significant drawbacks.

In order to spend anything on the lightning network, you need to have funds locked in a channel with a hub. And you can only spend the maximum that is in your hub. Likewise, you can only receive up to the maximum that the hub has put in the channel. In other words, your net credit or debit balance can't exceed the maximum put in by the other side.

There are some significant user experience drawbacks to this approach. I want to send someone $100, but I only have $50 in my channel. So now I need send $50 more of bitcoin and wait 20 minutes for confirmations. Then I can send the $100. It is even worse if I want to receive $100. Now the hub (bank?) has to approve my request to "receive" $100 because it costs them fees and capital to fund the channel. Make no mistake, the hubs will pass these fees on to you, the consumer.

Suddenly this starts to look a little more like Paypal then we want. Granted it is a better version of Paypal - there can be multiple, interoperable hubs - but with small blocks, funding transactions will not be cheap.

In a small block world, Lightning network fees will likely be more than you think. It could easily cost $10 worth of bitcoin for both sides to fund a $1000 channel. Why would I want to tie up $1000 to use this. I'd rather just pay the 3% to send via Paypal.

Why should lightning fees be high if there is an open market for hubs and they compete on fees?

Running a hub could end up being expensive as you need a massive amount of "collateral" to lock in your channels. A hub is rather worthless if it only provides $1 channels to all its "subordinates".

If you have a huge "bank of america" hub connecting to hundred of thousands of entities through large channels on one side and a small "mylightninghub.io" with a dozen of people through $10 channels you better hope that they're extremely competitive on fees to make up for it.

It's almost exactly like the credit card business currently. If I come to you and tell you "Here's the SimiasCard, it has extremely low fees and great advantages! But you're limited to $5 a day and it's basically accepted nowhere." Would you take it?

Internet connection? It's under 128kbps, less than a 2 channel ISDN link.

And for someone that cannot afford a 100$ drive every 5 years, toss the old blocks after saving a checkpoint and just keep the last X months plus UTXOs?

How does this improve with offchain transactions? What's the point of validating the blockchain if it's no longer a peer to peer network? That can't be any better than validating from checkpoints.

> It's under 128kbps, less than a 2 channel ISDN link.

How long would it take you to download the initial data? I don't think a 2 channel ISDN link could ever catch up.

I'm saying the extra connection is only that much. Right know such a link would take half a year to catch up. If it increased to 8MB, after a year the blockchain would be about half a TB, so with a 1Mbps connection you could catch up in 50 days.

But again, you can't compare this to going offchain! You can never catch up with the private networks doing settlement on BTC. But if you just want to validate going forward, then you need 2GB of UTXO data, plus a checkpoint hash and you can validate from there on out.

Not everyone running a node has a plethora of available resources for it. It would be great if we could keep scaling bitcoin by just increasing the blocksize, but by the time you get to a block size like 8MB or 32MB, things get really difficult.

From a Bitfury paper on the subject [1]:

8MB blocksize requires: 411GB/year extra space, 1184kB/s average bandwidth, 35.4TB/year bandwidth, and 32GB RAM.

If that isn't enough to scale, which it won't be if Bitcoin is to fulfill its goals of being able to compete with the currently leading payment networks, take a look at something like 32MB blocks:

32MB blocksize requires: 1643GB/year extra space, 4736kB/s average bandwidth, 141TB/year bandwidth, and 128GB RAM.

Although these numbers are possible to meet, it's obvious that not everyone is going to have hardware like this just to run a Bitcoin node. So it's predicted that so many nodes will be excluded for larger blocksizes (90%+), that the decentralization will take a huge blow.

[1] http://bitfury.com/content/5-white-papers-research/block-siz..., page 4

And what kind of blow will decentralization take when no one wants to run a node that only serves the purpose of settlement for a few large players?

The BW calculations are misleading - that counts transmitting the blockchain to other nodes. To validate transactions and participate, you don't need to upload it, only download. Also, if we consider transaction history irrelevant since Lightning or other offchain solutions are OK, then all that is needed is the last few blocks and UTXO.

As Satoshi said, once client-only is in, it doesn't really matter, and the answer is to not care how big it gets. (Sure, quoting him isn't an end-all, but it shows the original design goals.)

Also, none of this explains why an increase to say, 2MB was never done, unless it's a game of chicken.

Many (most?) people have a 1TB/mo cap.

8MB blocks is only about 33GB/month.

People won't even be able to start participating because they can't download more than 1TB in a month.

They can start with just the UTXOs, 2GB, and the last few blocks plus a checkpoint.

which has to be from a trusted source because you can't verify anything with just the UTXO + last few blocks.

Indeed. My main concern is that core tech (e.g. the standard Bitcoin app) has never had a massive security breach. But the only way to use it is if consumers can realistically download the entire blockchain.

I guess it was just a matter of time until this happened, though ideally it would've been many years rather than two years.

You always need a trusted source! So making the trust the first block or the millionth... Not sure there's much difference.

Except that the first block and the millionth are not of equal value so there is very definitely a difference in risk when trusting one over the other. The information that the millionth block is safeguarding is way more valuable than the information the first block is guarding. You can't really treat them equivalently.

Source please.

https://dataplan.xfinity.com/faq/

https://www.engadget.com/2016/10/06/comcasts-1tb-data-caps-s...

It's "only" $50/mo extra to get unlimited, but if you don't have it then it can cost up to +$200/mo.

It's true that decentralization will decrease if/when Bitcoin nodes require significantly more resources to run. But LN isn't good for decentralization either. Most big blockers want to maintain decentralization as well, they just think that it's better to try to scale the blockchain instead of scale via third party companies.

Anybody can run a LN hub just as easily as they can run a Bitcoin node. You don't need to be a company to run a LN hub.

There's no reason to expect that every block, especially in the near term, will approach that 8MB limit. It will scale with actual transaction volume instead, as Bitcoin did before the 1MB limit became a problem -- 1MB blocks were exceedingly rare; the block growth was fairly steady until it hit the upper bound. [1] It's reasonable to expect that the block size curve will continue to rise with transaction volume, but capping out the full 8MB is unlikely for some time.

[1] https://bitinfocharts.com/comparison/bitcoin-size.html

1tb drive = $50. 1 year of data costs about $16.

> I understand the reason for a larger block - it seems like it's pure profit for the miners

Bigger blocks = more supply. Wouldn't the cost go down?

The cost per byte would go down but the number of bytes would go up.

Transaction fees would go down while the cost of operating a fully validating node would go up.

> I understand the reason for a larger block - it seems like it's pure profit for the miners (should we just refer to it as greed?)

As space in blocks becomes crowded we should expect transaction fees to grow, and indeed they have: https://bitinfocharts.com/comparison/bitcoin-transactionfees...

If space in blocks is abundant then transaction fees should settle at the approximate per byte cost to the miner of the additional transaction.

I would expect smaller block sizes to be more profitable for miners, all else being equal (e.g. ignoring that high transaction costs make BTC less valuable).

1) It will grow by 1GB/day only if the blocks are full. Which they won't be for a long time, unless that branch becomes much more popular.

2) 8TB drive is $175 on Amazon. That alone can hold ~1 thousand days of full blocks. That's almost 3 years worth of blocks. By then the HDD prices will likely be even lower.

3) If some regular user will want to mess with the whole blockchain (which is such a strange argument, most don't care for it), downloading 8TB of data takes less than 18 hours on a gigabit connection. It will take years to get to 8TB.

4) There's no real objection to SegWit, as long as it comes with the large blocks. But consider what happened with Segwit2X - as soon as Segwit support solidified, a talk of ditching the 2MB extension started, a classic bait and switch. It's all over /r/bitcoin.

Decentralised, consistent, fast. Pick two.

And with SegWit about to lock in, lightning is beginning to look likely

Wouldn't be full from day 1, that's for sure.

Reply on news.ycombinator.com