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.
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.
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 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...
> 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.
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.
>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.
>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.
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?
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.
> 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.
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.
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.
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.
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.)
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.
> 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 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.
> 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
"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:
> 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
Do I have this right? Some miners want to increase blocksize, keeping Bitcoin in line with its original "peer to peer" nature, and thus are going to do Bitcoin Cash, with 8MB blocks to start.
Others want Bitcoin to become a settlement layer, and certain backers have said that $1000 tx fees would be great, since that means BTC won as a settlement layer. This kills the peer to peer aspect though, and end users would rely on offchain third parties to actually get transactions done. This group has fought to keep small blocks, despite recent congestion and increasing fees. The argument is that increasing blocksize can't solve all problems so why even start, and that increasing it even a bit would somehow prevent regular people from validating the chain.
Complicating matters a bit is that some miners have an optimised way of mining, exploiting Bitcoin block header layout to get an optimisation during hash calculations (AsicBoost). This is a 20% advantage but also encourages mining occasional empty blocks. AsicBoost is incompatible with many suggestions of changing the Bitcoin protocol, giving economic incentives to object to such things. This muddies the water.
On the other side, companies have invested a lot into becoming clearinghouses (Coinbase) or inventing ways to do offchain tx (Blockstream) casting doubt on their intentions of killing P2P and making BTC just for settlements.
It's not clear to me why an increase to 2 or 4MB wasn't done though. Perhaps to force the issue?
> It's not clear to me why an increase to 2 or 4MB wasn't done though. Perhaps to force the issue?
Yes, and it seems also out of spite. They could have increased to 2MB in order to avoid the horrible congestion on the network for a couple years. Once that was in place, they could have continued the SegWit work.
In fact, originally, everyone was in support of SegWit. Even the big-blocks camp (we can see that from the New York Agreement, where virtually the whole industry supported both big-blocks and SegWit). The only reason so many like Bitcoin Cash are against it today is because the debate has become emotionally-charged and us-versus-them. SegWit is an all-around good idea.
But the Core developers held out from a blocksize increase because, once they had declared that going from 1MB -> 2MB would be the end of the world, the network would become "centralized", etc, they didn't want to walk it back and simply compromise.
IMO, this is the main reason the ecosystem is migrating to Ethereum. It's not because of the Turing-complete scripting that is possible on Ehtereum, it's because development has been a lot more sane.
Despite the problems they've had (e.g. the DAO), the Ethereum ecosystem is more diverse and professional. They rationally discuss problems and make tradeoffs. They encourage alternate implementations, whereas the Core folks have engaged in baseless fear tactics to ensure theirs is the only implementation on the network[0] (and not talking about protocol changes--simply alternate implementations of the same protocols and consensus rules).
I think unless these leadership problems are addressed somehow, Bitcoin is going to fade into obscurity as others, like Ethereum, lead the way.
I'd like to comment about something I realized when reading your post. About the difference between the Bitcoin development/community and the Ethereum one. If you want to completely oversimplify it, the Bitcoin community appears to be full of fear, anger, attacks and competition among themselves. While Ethereum seems to be compromise, inclusion, discussion, working towards a greater goal. You see a change proposed, and one developer comments that they think it's a bad idea for certain reasons. Then after a month of discussion he will come back and say that, yeah, I was wrong, it's actually a good idea.
The recent multi-sig wallet hack was due to some bad refactoring by one of the developers on the Parity node/wallet team. Gavin Wood wrote a post about it, and instead of blaming his employee, he blamed himself, that he didn't put enough security into the Solidity language itself. And then he proposed some changes to make it safer.
There definitely was some ugliness with the ETH/ETC fork and controversies, but now we have pull requests from ETC developers that help improve ETH.
There seems to be a lot less ego in the Ethereum developer community. The fighting inside the Bitcoin community leads to attacking other communities too. Whenever there is a setback or hack or just the Ether price drops a bit, the threads are full of Bitcoiners coming in to laugh, attack, 'concern troll'. But you rarely see the reverse. Usually the attacks on Bitcoin come from the people who think all cryptocurrencies are a scam, they target everyone equally. Of course there are exceptions, there are amazing people in Bitcoin and horrible people in Ethereum. I'm just making a broad generalization on the feeling someone gets when reading and talking in their communities.
It's no wonder that Ethereum has the largest developer interest, it's just a really nice place to work.
Exactly. To make an analogy, consider what would happen if the president/congress appointed an incompetent fool as the chair of the Federal Reserve. The whole world would lose confidence in the dollar, and another currency would take over.
This is why I agree with Mike Hearn that the "Bitcoin experiment has failed"[0]. In fact it already did so in late 2015.
He makes technical arguments there which you could debate (some of his technical arguments have been shown to be misleading[1]).
But I think where he hits the nail on the head is that Bitcoin is now simply a circus. Unless the community can be united again, it won't last.
The Reddit censorship, DoS attacks, "scaling" conferences where solutions are not allowed to be proposed. It's childish, and almost shocking that people have stood behind their ridiculous behavior for so long, when they are on the verge of changing the world economy.
I rarely comment on Bitcoin these days, although I do still read things about it from time to time. I realise we're mostly in agreement, but on the technical arguments I'd like to briefly defend myself here - the arguments I made were not misleading or dishonest in any way. It's rather the post you link to which is.
No particularly special Bitcoin knowledge is required to figure out why, just careful study of that post with a critical and analytical mind (and not the mind of a "fan"). I wasted far too much of my life dealing with people Peter Todd had deliberately confused back in those years - it's a Sisyphean task that simply never ends if you let it - so I don't wish to write out a long rebuttal now, especially as I don't know you. But see if you can figure it out. Like I said, you don't need me to explain if you study things carefully.
As I said to Peter Todd in that thread, I'm a neutral observer and a fan of both of yours. Having been a programmer for over a decade, it's a shame that even someone like me can get so lost in the rhetoric of this debate.
Thanks for all your blog posts, I point people to them all the time. My greatest wish (something I tried to communicate to Peter Todd) is that Core would write some thoughtful, clear, well-argued posts like yours.
But I suppose it doesn't matter, because as we both agree, the experiment has already failed.
There's also no shortage of the Ethereum community patting themselves on the back too. The Ethereum community isn't toxic because it hasn't encountered serious questions about the future of the protocol yet and the price is constantly going up (in the medium/long term).
I'd say the Dao hack and fork was a very serious question, getting right down to the entire point of a blockchain itself, immutable or not. And the fact they are now able to work side by side (eth/etc) on some code issues is a very good indication on how the dev community there works differently.
During that crisis it got quite ugly though. Maybe it could be argued Bitcoin is going through a much larger, multi-year ugly period, and that things will settle down and cooperation will happen in another couple years. But many of the people claiming leadership and some of the core developers are outright toxic, and that 'trickles down' into the community.
> Yes, and it seems also out of spite. They could have increased to 2MB in order to avoid the horrible congestion on the network for a couple years. Once that was in place, they could have continued the SegWit work.
This statement demonstrates a very shallow understanding of the blocksize debate. There are a large number of reasons to object to any hardfork (causes instability and chaos, breaks compatibility, is a point of control for the people dictating the hardfork, is potentially opposed by many users, no easy way to measure support), and even more reasons to oppose a block size increase hardfork (doubling the blocksize worsens bottlenecks that are already significant, buys only a few months of time, is not a repeatable strategy to achieve real scalability, and the fight seems much more about control and pride than the actual block size - otherwise segwit would have been adopted immediately).
As bitter as the fighting has been, the opposition to a block size increase hard fork stands on very solid ground.
Right. I've been describing it like this: That Bitcoin doesn't have a Good King anymore (Satoshi). Ethereum has Vitalik, and Linux has Linus. Projects with a Good King typically defer tough decisions to the king, and the project is (usually) overall better off for it. But with Satoshi gone, everyone has their own ideas about what's "best" for Bitcoin, and there is no unifying force. Ethereum development is sane because Vitalik is heavily involved in it. I believe that is why Ethereum will succeed over Bitcoin in the long run.
All good kings eventually die. So projects without a good king are more future proof if they survive because they have already priced that reality in. The other projects could very well collapse once their good king dies.
Perhaps. But which project is more likely to survive into the future: Bitcoin, or Ethereum? I think having a good king steers a project well enough to future-proof it in most cases, if for no other reason than that it's engineered better along the way.
> Others want Bitcoin to become a settlement layer, and certain backers have said that $1000 tx fees would be great, since that means BTC won as a settlement layer
This is dramatically misconstruing the legitimate points made by the anti-big-blockers. The simplest fix would be to say "Others _are content with Bitcoin becoming a settlement layer_".
Making changes is always dangerous given the fact that Bitcoin is fundamentally a consensus-driven protocol. So far, none of the block size proposals has managed to garner a significant consensus. Here I mean "consensus" in a general version of Satoshi's "one CPU one vote" consensus; that's the only consensus here that is resistant to Sibyl attacks.
In addition there's the argument that increasing the block sizes necessarily entails increasing the orphaned block rate, which decreases network security. This happens because the larger the blocks are, the longer it takes for the network to recognize a legitimate block, and thus begin mining on top of it -- any mining that takes place after a block is found is wasted power and does not contribute to network security.
There's also the notion of long-time viability of the decreasing block reward without developing and addressing the problems on forming a fee market to ensure that miner compensation is commensurate with their costs so that subverting the network will always be dramatically more expensive than helping the network.
Finally there's the argument that block size increases make it more expensive to run full nodes by increasing space requirements.
These are real concerns, not just some notion of "increasing blocksize can't solve all problems why even start".
It happens that I disagree with this view; the first argument (forks are tricky) is, in my mind, the only valid one, and if Bitcoin Core threw their efforts behind finding a good, non-gameable, non-spammable block increase implementation, then we could get consensus.
>It's not clear to me why an increase to 2 or 4MB wasn't done though. Perhaps to force the issue?
Segwit, which activates on Bitcoin soon, already increases the the block size to ~2MB. Because Bitcoin Cash doesn't implement Segwit, increasing to merely the same size as Bitcoin wouldn't have been compelling.
Increasing the block size is a fundamental change requiring a hard fork and a chain split. It is not possible to continue on the same chain with a 2mb block. However, they could continue on the same chain with segwit which gives the rough equivalent of a 1.7mb block. Unfortunately, that wasn't enough for the other side (+lots of other reasons, valid or not, I couldn't say).
Don't be fooled into thinking a soft-fork is the "same chain". It simply tricks nodes that don't know about SegWit into validating transactions that they don't really know how to validate.
It's possible for a non-SegWit miner to accidentally mine an invalid block after the soft-fork. Here is how.
The "backwards-compatibility" of SegWit comes from the fact that it looks like an anyone-can-spend transaction. Meaning, on the old blockchain, those coins would be up for grabs.
Nodes that support SegWit know that it is not really an anyone-can-spend transaction, because they have extra data not included in the blockchain.
But a node that doesn't upgrade doesn't know about this. So here's what could happen:
1) Bob sends sends a SegWit transaction to Alice
2) The non-SegWit node sees it as an anyone-can-spend transaction where Bob is basically giving up his coins
3) Eve wants to mess with the non-SegWit node, so she sends it a (valid!) transaction which spends Bob's coins and sends them to Eve
4) The non-SegWit miner mines a block with that transaction, and the block is consequently rejected by the SegWit nodes
So SegWit needs 51% of hashing power in order to work, just like a hard fork. Without it, they wouldn't be able to reject the block with Eve's transaction, which would've been valid on the old blockchain.
The only difference is that the above edge-case exists for a soft fork, whereas for a hard fork, non-upgraded nodes would simply be split into a smaller network instead of being tricked.
Not quite, it needs 51% of hashing power in order to be safely backwards compatible with non-upgraded nodes, however it's always safe with upgraded nodes. That's the reason BIP9 has a 95% activation threshold.
Note this is by far not the first soft fork Bitcoin has done. P2SH, CSV, and CLTV for example were also soft forked in. The original design even included 10 blank opcodes designed for soft forking in features.
> 51% of hashing power in order to be safely backwards compatible with non-upgraded nodes, however it's always safe with upgraded nodes
Yes, what I was pointing out is that in a soft-fork there is a risk of an eventual re-org, whereas in a hard-fork there is not. It's a minor risk, but it exists.
I also believe that any non-SegWit miners will be pushed out of the network using the mechanism I described. It would be pretty easy to trick them into mining invalid blocks.
Let's see if I understood this correctly: once the network splits into BTC (with SegWit) and BCC (without SegWit), if someone spends an old BTC coin (where old = from before the split) using SegWit, anyone can "steal" that same coin on the BCC "mirror universe"? Sounds worse than merely replaying a transaction from one chain into the other. That's so going to be a mess.
Correct, though this isn't really anything special about SegWit. If BCC had forked right before Bitcoin added P2SH for example, the same would have resulted from P2SH transactions.
Actually, since BCC is a hardfork, they can make the Bitcoin Cash spending rules whatever they want. They could have made SegWit transactions totally unspendable if they wanted. They could have made all Bitcoin Cash corresponding to the Bitcoins sent to Blockstream spendable by anyone, etc.
The argument is that higher cost of node operation is actually what kills the "peer to peer aspect." Trustless second layer networks such as Lightning use "third parties" to route money across the network, but never in a trusted/custodial fashion.
The lightning network works just fine as a daily transaction layer. Increasing the block size would never work as a large scale transaction system because the block size would have to grow to 100s of GB a day to reflect even a small percentage of total transactions. It's a short term hack that creates problems down the road.
Bitcoin actually rarely changes, which is why this is a big event. You're probably thinking of all of the shitcoins/ICOs that come out nearly every day - make no mistake, those are a cash grab.
This is only a big event if you choose to run the BitcoinCash software. If you stick with Bitcoin-core you aren't even going to notice that a thing happened.
It's still a big event in that all of the exchanges have had to take a stance on the fork. And there will be an initial competition between the two forks, like with Ethereum and "Ethereum Classic" (in that case, the new fork actually won over the unchanged version).
It matters for the ability to convert BTC to other currencies (like USD), right? If I'm understanding this right, an existing bitcoin is now valid in both the BTC chain and the BCC chain, and presumably the world isn't going to let you sell the resulting BTC for its previous value and the resulting BCC for its previous value (since the two sales would now be transactions on two different chains). So unless BCC fails completely, the market value of BTC will be reduced by the market value of BCC, which seems like a thing you'd notice.
Yes, this is right, but it appears that the value of the original coin and the forked coin don't correlate with one another too strongly after the fork. I mean here that it appears that the market value of BTC will not be reduced by the market value of GCC, in such a manner as you suggest. The less popular coin after the fork certainly is less valuable, but after the fork, the two values follow their own destinies, unrelated to one another.
Something I haven't seen in the comments yet: it's a realistic possibility that the Core team will make a change to Bitcon's proof-of-work, with the explicit goal of shutting down miners' efforts to implement the "2X" part of Segwit2X (a block size increase).
So while disaster has been avoided for now, and Bitcoin Cash is unlikely to garner much support, they could become the longest chain within a year or two if they keep at it. As the Bitcoin Cash developer said in the article:
> If the Segwit2x agreement fails to implement the 2x part, which is not entirely unreasonable, and only ends up being being basically SegWit without the 2x, many miners will likely defect to Bitcoin Cash.
He's right. The Core-versus-the-world battle is far from over.
But what I would call "most of the industry" supports a block size increase, in addition to SegWit[0].
As I said in the parent comment, rather than making a compromise with this huge portion of the community, Core has discussed changing the proof of work algorithm in order to shut them out.
I don't think "Core versus the world" is hyperbolic at all.
EDIT: To add to that, remember that Core had to propose a soft-fork which risked a chain split in order to force SegWit into activation. Many were holding back support for the promise of a block size increase. That is why SegWit is now going to lock in: because the New York Agreement folks rallied together, compromised like adults, and agreed to implement both SegWit and a block size increase.
Still wrapping my head around the Bitcoin ecosystem, but listened to an interview of Nick Szabo by Tim Ferris where Nick pretty explicitly indicates that increasing the block size isn't a good idea and shouldn't even be a debate. He makes it sound like anyone in the "know" understands this.
What is the argument for the other side?
A Reddit post has the quote here, but I recommend the whole interview.
Satoshi said blockchain size isn't an issue, and the solution is to not care about how big it gets. For this guy to pretend this is some super advanced thing mere mortals can't understand and shouldn't talk about is obscene.
However, I think it's incorrect to say most developers disagree with increasing the block size or a hard fork. Segwit increases the block size, as do hard forks proposed by some Bitcoin Core developers like Spoonnet [1]. There is just a general dislike towards the existing technical proposals.
We must look very closely at experts who made the argument that anyone who is an expert agrees and understands this. If you do not agree you are not in the 'know'. This shouldn't even be discussed now that experts like myself have stated our opinion.
This topic seems technical but at it's core it is about self interest, fear and money.
> He makes it sound like anyone in the "know" understands this.
That's quite telling, isn't it? There's this huge debate, but his argument is that it's obvious?
From a 'tradition' or 'legacy' standpoint, the blocksize limit was never meant to be a persistent thing. It was not present in the whitepaper or the initial implementations, and when Satoshi added it, it was explicitly stated that the limit should be raised as needed and as computer hardware and network capacity increased. When Satoshi left, the project was handed to Gavin, who has gone to great lengths to support blocksize increase. Similarly, other early developers like Jeff Garzik and Mike Hearn strongly support on-chain scaling. I think it is quite fair to say that the original intention for the limit was simply an anti-spam measure, and was not intended to limit network usage, for whatever that's worth.
Larger blocks require more cost to run a node. It costs more network capacity, more storage, more time to spin up a node, etc. The argument is that these costs will decrease node count to a dangerous degree. More network use could, however, create incentive for more people to run nodes. Clearly there's a trade-off between extremes, so a careful consideration must be made about where the best trade-off occurs.
Larger blocks are a liability to miners as they increase the chance of orphaned blocks. This has two primary effects: it places a natural limit to the block size miners are willing to mine, and it creates incentives for miners to have excellent network access to the rest of the network. This later issue can mean mining centralization. This is one of the core arguments against increasing block size, but it's a very complicated issue. One of the primary confounders is ASIC development, which means rapid capital turnover and short investment timelines for mining. As ASIC development reaches state-of-the-art node sizes, and also as the Bitcoin price stabilizes, mining investment looks very different. This is very difficult to predict.
Small blocks greatly limit what Bitcoin can do. It places a hard cap on transaction throughput. The formation of a transaction fee market greatly discourages small transactions, making Bitcoin inaccessible to a wide range of people. It makes any address with Bitcoin less than the txn fee effectively unspendable. In the extreme, it limits Bitcoin to the role of digital gold, a speculation vehicle with little use as a medium of transaction.
There are two big open questions:
* Will larger blocks lead to dangerous centralization?
* Will 2nd layer solutions provide effective scaling solutions?
In the end, all of this deals with trade-offs, but worse, trade-offs with difficult-to-quantify risks at either extreme. I simply would not trust anyone that is dogmatic about their favored approach.
My personal view is that the conservative approach with least risk is to permit moderate blocksize increases while 2nd layer solutions are being developed, and to continue the debate as the network develops. This is, in effect, exactly what the '2X' compromise does.
This is not surprising. The miners (or I guess I should say "some miners") want to retain their power by keeping all transactions on-chain in Bitcoin Cash, but I think at the end of the day a coin only has value if it has wide acceptance in the community, mainly including the people who actually use it for transactions. I think Bitcoin Cash will fail, but in the short term people will try to see how far "greater fool theory" will go by selling their Bitcoin Cash coins while still holding on to their bitcoins on the main blockchain.
> want to retain their power by keeping all transactions on-chain in Bitcoin Cash
Exactly what power is that? The power to collect smaller mining fees?
Honest question - what's the status of Lightning? Core promotes it as the solution to scaling and it's essentially a page on github. Litecoin already has Segwit and no one is using Lightning. Am I missing something here?
Lightning implementations exist and are fairly usable (although I've found there is some disagreement on e.g. public key format for peers). Check out the following:
Do these projects have the nicest UX? No. Is it fairly trivial to hook up a shiny UI to their RPC interfaces? Yes.
It's going to take a bit to roll out the infrastructure necessary, but a 1.7 MB block size is good enough until then. Especially if miners stop using ASICBOOST and mining near-empty blocks.
That you'll buy it so you can sell it to the next, greater fool to come along. The bubble keeps expanding as long as people think there are "greater fools" to take it off their hands.
Because I think there will be a lot of people who don't think that Bitcoin Cash has long term value, but will try to make a quick buck off it before it goes to 0.
Another difference is the project says it will support multiple implementations of its software, a move that's not surprising given the criticism that Bitcoin Core's software is too dominant on the bitcoin network.
What does that mean exactly? Bitcoin being open source and anybody being able to connect to the network means that anybody can fork the client if they want to, doesn't it?
After all that's exactly what this Bitcoin ABC fork is doing.
What they're trying to say is they'll support multiple implementations of the software on the same network (unlike Bitcoin ABC, which is a fork of the software and a fork of the network).
But Bitcoin already supports that too. There is bitcoin core, bitcoin knots, bitcoinj, btc1, bitcore all running on the same network.
I think they also may be referring to some Bitcoin Core authors recommending against other implementations - the concern is if the implementations contain an error in the consensus code, they could accidentally fork off, and potentially lose funds for the user. For similar reasons, Bitcoin Core builds reproducible static builds and recommends those, the minimize the chance of behavior divergence.
But you're right - it's merely a suggestion from a portion of the developers, and it certainly doesn't stop anyone.
>Indeed, the cryptocurrency is currently trading at $461, meaning it's worth about 18% of bitcoin's current price of $2,568, in an already-open futures market.
This statement needs a lot of asterisks added to it imho.
BCC has been trading at $600K USD volume in the past 24 hours [0] compared to Bitcoin's trading volume topping over $600M USD in the same time period.
BCC futures have only been trading on a single, unpopular exchange, that does not allow withdrawal of the coins being traded until only after the fork takes place.
If you can send them BCC to trade before the fork, I fail to see why you can only cash out after the fork.
I'm all for Bigger Blocks, but claiming that BCC has 18% support of the community based on that single price valuation is extremely misleading imho.
From a volume standpoint, I would argue that it has less than 1% support of the community at large.
Chains splitting off is a very interesting phenomenon. Just like with Ethereum Classic splitting off Ethereum, the value of the original chain can be divided into two, albeit unequal, parts. The process may even create new value - though I suppose it might just as well destroy value.
What I've also wondered about though is multiple chains combining into one. Does anyone know if this has happened before?
I believe there is a strong analogy here to how company stock can evolve, when companies are either split out as separate entities, or merged into one, respectively.
> multiple chains combining into one. Does anyone know if this has happened before?
I don't think it happened on any meaningful chain. It could be donetechnically through a proof-of-burn on the giving chain, and the corresponding minting on the receiving chain.
Something loosely comparable would be conversion from a token to another within the same blockchain, and this must have happened quite a few times on Ethereum; but that's within a single blockchain, so arguably doesn't count.
However when you see how difficult it is, in terms of governance, to address such an obvious issue as Bitcoin's tiny throughput, I can't imagine two distinct chains agree, in a timely fashion, both on the principle of a merge, and on the way to execute it. Maybe on-chain governance, as proposed by Tezos, will fix this problematic indecisiveness on blockchain evolutions, we'll see.
I haven't read the Tezos paper yet but I will add it to my reading list. Thanks!
I do think there is a lot of potential room for improvement in how blockchain governance works, especially in terms of delegate voting.
Maybe it is more reasonable to expect a majority portion of one chain and a majority portion of another chain to merge, leaving behind two stragglers, and then allow those who continue to hold the old tokens to buy in later at a decreasing discount.
Multiple chains that have diverged in the past can never join together. Unless you want to double the amount of total coins in the network. Its technically possible if two different chains wanted to merge they could decide on which block they will merge at, but there is the huge issue of agreeing on an exchange rate between the both old coins to the new coins.
From a strict ledger of transactions metaphor of the blockchain they could be joined without double value but it'd require that all blocks from both chains were strictly disjoint sets of transactions and no account overspent when combining both chains. On a more real technical level though the protocol doesn't have a way to have two parent blocks even if the two chains satisfied the conditions to avoid double spending.
Right, and that's a lot like agreeing on an acquisition price in the case of a merger. There too stock in the acquired company is commonly traded for stock in the acquiring company at agreed upon prices.
And technically, I think it must remain possible as long as you can always simply issue a new token with a certain starting distribution.
One important detail that this article is missing is that the proposed fork forces a new sighash. This is important because it prevents a replay attack.
This whole thing is actually really straightforward if you evaluate it from the perspective of governance. In bitcoin, miners run software and the software they run controls the performance of the network. Miners therefore control the future software state of the network.
Anything that moves transactions off of the network or decreases the number of miners queried per transaction is therefore antithetical.
If you are a miner, lightning and segwit just hurt you. The only way you'll allow them is if you believe that to do otherwise would slay the golden goose.
The counterpoint to this (not that I necessarily disagree) would be that 2nd layers solutions add new value to the network, and thus add value to a Bitcoin transaction. This is very likely to occur to some degree (e.g. micro-transactions and fast retail transactions that Bitcoin can't do), but will also cannibalize some on-chain activity.
Also, altcoins present a real competitive risk; failure to maintain an advantage over them will see network value approach zero.
It's quite possible that this fork is negligible for awhile. But because parties such as Core will likely refuse to let the segwit2x part of segwit happen [1, many others], if the miners follow through on their promises, then this could be real entertaining to watch if the larger miners start switching to BCC during this later period.
Just like when ETH split into ETH and ETC, it seemed as if almost everyone dumped their ETC coins as quickly as possible. But contrary to what most predicted, the chain ended up having real value. It seems like quite a few Bitcoin holders are planning on doing this as well, although many are being more cautious this time around and holding their BCC instead.
You don't want to sell your stash of the next Bitcoin, just in case you're wrong. These things are impossible to predict for normal investors.
> You don't want to sell your stash of the next Bitcoin, just in case you're wrong
If you think that the price will first crash and then bounce, you might want to sell your stash and then buy it back at a lower price. To keep the price up it wouldn't be enough to have many who wait and see; you also need lots of buyers for all the BCC that will be sold by those who have BTC and will want to get something out of their BCC as soon as possible.
I've got some stored in a client called bitcoin-qt, which I haven't opened in years and I expect would take months to catch up with the block chain as it is. Should I be worried about trying to shift them before (or after) the fork? Am I likely to be tied into which ever fork the bitcoin-qt maintainers support? Should I be trying to transfer to a paper wallet before the fork?
If you haven't opened it in years, do nothing. Wait for the dust to settle. Then you can decide what to do with it; whatever you have in that wallet will still be valid on both sides of the fork.
So... were I a bitcoin holder at the present time (I'm not) then I'm potentially going to have those same bitcoin on two chains? So depending on what value is held in either chain this could be a huge financial boost?
Unless of course this tanks the system entirely, but that seems unlikely.
Most likely the sum value of each token is not going to be much different from the pre-split value of the original token. Or if it is, it means that people on both sides are relieved and optimistic about this technique for conflict resolution, and really do see it as value added.
If you care about one token over the other, the best thing to do is let the dust settle, then sell all of your non-preferred token for the preferred token. Financially, this should not set you back even if you prefer the minority token - you just end up with a bunch of them, and the total value of your wallet is still about the same.
Bitcoin isn't worth $2500 per Bitcoin by magic. It's worth that because of supply and demand.
The only change might be that some of the demand shifts to BitcoinCash instead of Bitcoin, meaning the price of both will be lower than the price of Bitcoin now, but they'll likely add up to about the same amount.
It has special meaning to people frustrated with the stubborn refusal from bitcoin-core to raise the block size. Bitcoin has two major factions, and this is more or less a peaceful way for them to split out.
I'm hoping it decreases the overall level of conflict, as both groups will be able to get what they want here.
The comments here (which overall are measured and reasonable relative to elsewhere) lead me to believe that this "us vs them" combative mentality will continue. It seems as long as there are two chains, supporters of one will still be trying to attack and hope for the demise of the other, even though I share your hope that the opposite will happen.
Question: according to Coin Dance[1], SegWit will lock in around 14 days from now. Will the max block size be what the SegWit code says, or the 2MB that SegWit2x has chosen? There is a majority of nodes running Bitcoin Core, but a majority of miners that run SegWit2x nodes. So what will happen?
What do you think the exchanges will do here (aka Coinbase) [Yes I know you should pull all your BTC off...].
If there is a hard fork, are they just going to wait until the dust settles and then give people access to both coins? I.E. BCC would magically appear in your account. Or do they seriously intend to not support one of the chains and just have all their users holding BTC worth X% less?
It's the culmination of a years-old debate. Looking at both arguments in a positive light, Bitcoin Cash wants to stick to the original idealistic vision of Bitcoin, and is offering a temporary solution for it. Bitcoin wants a better solution, and is ready to make some ideological compromises in exchange for growing the chain faster and making it easily usable.
I don't think there was anything about the "original idealistic" vision of bitcoin that was explicitly against secure off-chain tx. Rolling back segwit is shooting yourself in the foot because your enemy told you that it was a bad idea.
Keep in mind, that there's an big amount of propaganda going on in the comments and a lot of selective arguments floating, so don't take a single comment for an absolute truth. (including this comment)
One thing is for sure, that there are many dynamics at different levels in conflict around this situation.
So if I have coin on, say, coinbase, what should I do? Should I withdraw it to a wallet before August 1, so I can access both Bitcoin and Bitcoin Cash?
I would not keep coins sitting in coinbase either way, so the decision is easy. Move it off. If you aren't planning on selling anytime soon then do it to a paper wallet or get a Trezor or the like if you want to actually use your coins.
But don't trust any third party with your coins, especially Coinbase which isn't sharing the private keys with you.
Absolutely not. Keeping coins on coinbase means on the split you have your normal balance, but coinbase keeps your bitcoin cash balance.
Take your money out of an exchange, it should not be kept there in the first place! If you don't own the private keys, you don't own your bitcoin. If it is on coinbase, you don't control it, you are just asking them for permission.
Lets keep the blockchain protocol in the mind for a second. Now, given that bitcoin is born due to some problem with banks that the creator felt, what can the banks do at best?
They can create a bank that cannot control printing of money by cryptographically publically proving the held amount and all transactions, backed by proof-of-work as a proof that they are revoking the rights to change their own books. How would such a bank look like?
It would look like BitcoinCash(currency)+Viabtc(interface of the bank)+Bitmain(guards)+this particular dev group(sales) all of them owned by JihanWu. This is a prelimn form of the ultimate bank of the future. Epitome of centralised money.
Will it succeed? Well for most people when they are asking this ques they are asking "will it rise in price?". Well I know there are shit ton of shitcoins that trade in the market, and this here is something that is the best form of something historically considered useful vs a group of people who are saying history was wrong and wanting decentralization but this group feels lost in this group noise of speculators.
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.