This was foreseeable when Bitcoin Core rejected Segwit2x. BitPay's business model simply fails unless the blockchain can scale much more than Segwit alone achieves, very soon.
BTC was fast and cheap when adoption was low.
These kinds of transactions aren't feasible on the Bitcoin chain since the fees are prohibitive, so all those small unspent outputs remain in the UTXO set forever and are essentially unspendable.
I'd also argue that increasing the block size scales fine as long as network speeds and storage continue to scale as they have been over the past years.
Also it is important to note that BTC could be like BCH at higher transaction levels if they increased the block size but that won't because of this lightning network idea. Which is what I don't get. You can increase the block size right NOW and work on the lightning network as well. Yet, they don't do that because the lightning network is everything and any other solution is not even considered.
I used to also think that bigger blocks were always bad but that is simply not true. The original block size limit was purely implemented to stop spam when bitcoin's userbase was very low. Satoshi actually wanted to implement bigger blocks as the userbase grew. Bigger blocks is the not the long-term solution but it is a solution that we have right now that works.
160,000+ bitcoin nodes are not interested in your centralization scheme, whether it is done 'steadily' or immediately.
But it could be years later; years in which other scaling solutions can be researched. If you only accept scaling solutions that can scale to infinity today, you will never accept a single one.
In fact, SegWit negatively affects decentralization because it is much harder to build and maintain your wallet because of all of the complexity of SegWit, pushing people to crowd around existing solutions.
And what happened? After they got exactly what they wanted with the doubling of capacity, they said "we want more" which demonstrated the entire exercise had nothing to do with blocksize, but about stealing the blockchain away from its users, and centralizing it in their data-centers. Which is why, months after the segwit implementation, the biggest and loudest people clamouring for a capacity increase for years, which includes bitpay, the subject of this thread, and coinbase, which has been an actively undermining the bitcoin developers for years, have not even implemented the blocksize increase. So much for blocksize being important.
All full nodes had to upgrade or risk mining invalid blocks.
http://luke.dashjr.org/programs/bitcoin/files/charts/softwar...
I don't think you really understand the relationship between nodes and consensus.
Hmm that's not how it used to be. You must be talking about something other than Bitcoin.
I've tried to refer to them using the less loaded "BTC" and "BCH" symbols instead; but it's kindof getting tiring, hearing people insist "Bitcoin Cash is Satoshi's True Vision". It's like somebody starting a "Apple Phone LLC" and saying it's Steve Jobs' true vision, ignore that other "Apple" company.
Just because the first generation of bitcoin was the beginning doesn't mean it still reflects the original vision.
Bitcoin : Peer-to-peer cash.
You went right over the first part, and only talk about the second part, even though in the first part, the word 'peer' is used twice.
If suddenly someone spins up a million bitcoin cash nodes will you call it bitcoin? If total PoW exceeds core will you? If core finally hard forks to increase the blocksize will you stop calling it bitcoin?
But that you'd compare it to Apple, that's just weird.
There is no reason that the name of an unauthorized fork of a cryptocurrency should use the name of the original within it.
In a decentralised system based wholly around cypherpunk distrust of central authorisation, you call something unauthorised?
I'm not sure if that's hilarious or just sad.
There has to be some acknowledgement that if you take someone else's work and modify it, you shouldn't then be allowed to claim you are them.
It is by definition a decentralised, anarchic system. The idea of authorisation or ownership of the one true core is hilarious.
That's great, but it's not what I wrote. What "one true core"?
Taking someone's software, modifying it, and touting your change as the next version of their software is wrong. Regardless if the code is meant for a block chain, or anything else.
Which is true, so what's the problem?
God knows what Satoshi thinks about all the stuff going on around bitcoin...
I guess I've decided - it's just sad.
I'm sorry you don't see that.
All I can do is guess that you are talking about users not only being inundated with forks, but not even being able to tell one fork from another, or even one coin from another because they all use the same names. And this is all fine for you because of anarchy or something.
It's an abbreviation. Bitcoin Cash = Bcash/BCH. This acronym is not confusable with Bitcoin or the BTC acronym at all.
Why is this considered remotely offensive? People are incredibly reactive to this and I don't understand why. It's a pretty straightforward mechanism of acronyms that has been going on for hundreds of years.
Why is this actually considered a serious point of discussion, at all?
(and the thing is, it's not even the bcash people who are bothered by the term - it's the BTC people! it's like you got insulted when someone recognized me enough to call me PMD... which is what I suspect it comes down to.)
That's not doable today, but it is not TOO far off.
And by the time adoption catches up, maybe the technology and bandwidth costs will be capable of supporting it.
The blocksize does not need to increase forever. All it has to do is replace all of the world's financial transactions.
- the whitepaper itself solved the storage problem with old transaction pruning.
- The block propagation and validation bandwidth requirements can be brought down 90%+ by canonically ordering transactions, memoizing transaction validation, and propagating only the block header and metadata.
- the inefficiencies in the actual code are being worked out by Bitcoin unlimited's gigablock project among others.
There is a lot of technical complexity to this, and no real working proof at scale (AFAIK there is no production implementation even at a small scale).
Lightning Network at scale will involve routing problems between coinholders analogous to a mesh network (or more realistically, FidoNet/UUnet) which risks centralization since those problems are not solved at scale in any fashion except hub-and-spoke/backbone. BGP is not an acceptable solution for LN since it involves a substantial degree of trust, and manual routing devolves into centralization.
You actually have to be able to say: "See, I found a route A-D through B and C: ABCD and all nodes are sufficiently funded to execute the payment."
And that's the big unsolved issue. Can you make an algorithm that will reliably do the latter while keeping the network decentralized?
I think this is very hard, as the channel states between individual nodes will change for each payment, and that's entropy that somehow needs to be synchronized.
Of course, simple centralized solutions like making B and C big enough ("banks") to deal succesfully with almost any payment are possible.
But solving this problem is pretty damn hard, and I have yet to see a satisfying solution to this. Note that satisfying absolutely must include being decentralized.
Because else, we can as well do the simple and sane thing and scale just on-chain, which also ensures that the miners get their fair share of the pie and makes it less likely that the bottom falls out because there's lots of layers, each taking a cut, to the system.
Now, don't get me wrong: I am fine with LN and I think it might have good use in the micro/nano-payment space. Regular, simple payment channels (like BCH and BTC have since the beginning) might fully cover that use case as well. Who knows. In any case, LN as the (and the only) solution to scaling is not going to work out.
We can't don't gigabyte blocks tomorrow, but that is within shooting distance.
Bandwidth costs have gone down by 20% every year for the last 20 years. And they will continue to go down, making on chain scaling absolutely doable.
Micro transactions will never work on a blockchain. But coffee transactions are definitely within shooting distance of possible.
Also, Bitcoin Cash had the annoying antifeature of using the same address format as Bitcoin, probably because it pretends to be Bitcoin, which means it's easy to accidentally send Bitcoins to a Cash address and vice-versa. Even experienced users seem to screw this up occasionally. (This certainly wasn't for reasons of wallet software compatibility; changing the address version number is trivial compared to the other changes required to port even a lightweight wallet.)
BitPay's workaround for this is apparently to use their own address format for Bitcoin Cash which is incompatible with most existing wallet software ("the BitPay and Copay wallets' BCH address format"). Non-BitPay wallet software seems to have backed a different, incompatible new address format as the solution to this problem. Of course, all of the wallet software is still going to happily let you accidentally send Bitcoin Cash to the Bitcoin payment address... it's only sending it to the correct address that may not be supported.
Bitpay's business model was always a bit of a special case. Undercut centralized services on fees? Not likely.
It'll work as long as there are early adopters to spend their windfall, but in the long run they'll need to pivot. And not to the next altcoin.
The Bitcoin developers (not "Bitcoin Core") had just implemented a block size increase after years of discussion.
The segwit2x intiative didn't take part in this. They didn't bother even writing a specification, let alone a proposal or take it through public discussion.
The last one (Segwit2X) had it's reference nodes so poorly coded that the mining nodes didn't even manage to mine their first block; due to 3 separate off by one errors that even basic testing would have revealed. Shoddy coding like that is yet another reason why the core devs (and the community) wanted nothing to do with the 2x team. And given how it took them months to fix BCH's difficulty algorithm, I'm not really convinced that they've improved.
> If you want centralized chinese government controlled crypto, there's bcash.
That's the pot calling the kettle black. Bitcoin core is China-coin.
The economics of mining mean that there will always be centralization. Mining will centralize where there is free or cheap electricity (ahem, China). Mining will centralize on the hardware of the single manufacturer with the most cost-effective asics (ahem, China). It inevitably centralizes as other miners will fall behind revenue-wise, and not be able to invest enough to provide meaningful hashpower over time.
The small-blocks-prevent-centralization line of thinking is just closing the barn door after the horse is out.
> Satoshi from the Bitcoin white-paper chapter 12 'Conclusion' : The network is robust in its unstructured simplicity. _Nodes_ work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. _Nodes_ can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this _consensus mechanism_.
First, you have to understand what 'consensus' actually means :
> https://en.wikipedia.org/wiki/Consensus_%28computer_science%...
> A fundamental problem in distributed computing and multi-agent systems is to achieve overall system reliability in the presence of a number of faulty processes. This often requires processes to agree on some data value that is needed during computation. Examples of applications of consensus include whether to commit a transaction to a database (or, for example, committing blocks to a blockchain), agreeing on the identity of a leader, state machine replication, and atomic broadcasts. The real world applications include clock synchronization, PageRank, opinion formation, smart power grids, state estimation, control of UAVs, load balancing and others.
What does this mean if you are but an intrepid traveler amongst the erstwhile numpty-folk?
Nodes are agents in a multi-agent system with an agreed set of consensus rules (https://www.cryptocompare.com/coins/guides/how-does-a-bitcoi...), which they and they alone enforce, that ensure that the system functions. Transactions are propagated through the multi-agent network based upon the agreed consensus rules by nodes, which are agents in a multi-agent system. Miners retrieve valid transactions from any of these nodes, which are agents in a multi-agent system. They then order the transactions, and perform a hashing function on them until the hashing function returns a value that is suitable to the nodes, which are agents in a multi-agent system. They then pass the new block that they've created to the nodes, which are agents in a multi-agent system. The nodes, which are agents in a multi-agent system, then validate the block to ensure that each of the transactions within the block agree with the consensus rules. Then the node, which is an agent in a multi-agent system, extends the block-chain by attaching the new block to it. They then pass the new block, if it is valid, to other nodes, which are agents in a multi-agent system. Then each of these other nodes, which are agents in a multi-agent system, each do the same validation on every block.
Nodes accept incoming transactions and validate them. Miners don't. Nodes replicate transactions to other nodes. Miners don't. Miners take transactions from nodes, and order them in a block, and perform a hashing function on them (the only thing they do). Miners pass the new block to the node. The node validates the transactions in the block. Miners don't. The node validates the block. Miners don't. The node extends the blockchain. Miners don't. The node replicates the block to other nodes. Miners don't. It is the validation of the nodes, and their CPU's, that define and police consensus in bitcoin.
There is only one function that miners do. They take transactions, put them in a block, and hash them. As soon as a miner produces a block that nodes don't want, it is rejected. Miners work. Nodes validate. So nodes are the proof in proof-of-work.
Nodes accept the transactions, validate the transactions (using their CPU), replicate the transactions, maintain the mempools, validate the blocks (using their CPU), extend the blockchain (using their CPU), replicate the blocks, serve the blockchain, and store the blockchain. Nodes even define the PoW algorithm that miners have to employ. If you can't convince these node owners that are using their node on a day-to-day basis, to uninstall their node software and install your new node client, especially when that node client decreases their node security and decreases the network security, any change you have is going to go exactly nowhere.
So nodes maintain the protocol, not miners. It is thus. It has always been thus. If you can't convince all of those node owners running their node clients to uninstall one client and re-install another, any change you have to consensus is DOA.
See for yourself. Download it. (https://bitcoin.org/en/download) It's currently at 0.15.1
https://bitcoin.org/en/full-node
> A full node is a program that fully validates transactions and blocks. Almost all full nodes also help the network by accepting transactions and blocks from other full nodes, validating those transactions and blocks, and then relaying them to further full nodes.
Changing the PoW algorithm (your example) would require these powernodes to vote for their own abolishment, if their $100M worth of ASICs can't support the change. So it's very unlikely.
Such a miner could do a double-spend transaction by first spending on the short chain and then reverting his transaction on the longest chain. See https://en.bitcoin.it/wiki/Majority_attack
> Nodes even define the PoW algorithm that miners have to employ.
Nodes change PoW algorithm and the old miners have expensive loud space heaters. They know this, which is why they didn't follow through on 2x. They knew that threatening that attack leads to one outcome : ruin.
It's a complex subject, sure. But I can't force you to understand how bitcoin works dude.
Satoshi's brilliant solution to the Byzantine generals problem of consensus is proof of work, not "nodes decide what code to run" precisely because nodes are vulnerable to sybil attacks.
-How would these nodes know that the 51% attack history is bad?
-A proof of work change is a hard fork, and these take months to deploy properly according to core.