SoylentNews is people
SoylentNews
In a test of Bitcoin's ability to adapt to its own growing popularity, the Bitcoin community is facing a dilemma: how to change Bitcoin's core software so that the growing volume of transactions doesn't overwhelm the network. Some fear that the network, as it's currently designed, could become overwhelmed as early as next year.
The answer will help determine the form Bitcoin's network takes as it matures. But the loose-knit community of Bitcoin users is not in agreement over how it should proceed, and the nature of Bitcoin, a technology neither owned nor controlled by any one person or entity, could make the impending decision-making process challenging. At the very least it represents a cloud of uncertainty hanging over Bitcoin's long-term future.
The technical problem, which most agree is solvable, is that Bitcoin's network now has a fixed capacity for transactions. Before he or she disappeared, Bitcoin's mysterious creator, Satoshi Nakamoto, limited the size of a "block," or group of transactions, to one megabyte.
Under the one-megabyte-per-block limit, the network can process only about three transactions per second. If Bitcoin becomes a mainstream payment system, or even a platform for all kinds of other online business besides payments (see "Why Bitcoin Could Be Much More Than a Currency"), it's going to have to process a lot more. Visa, by comparison, says its network can process more than 24,000 transactions per second.
(Score: 5, Informative) by JNCF on Wednesday May 20 2015, @02:32AM
From TFA :
Ultimately, though, the decision-making process “really comes down to how the core developers feel about it,” says Narayanan, since they are the only ones with the power to change the code.
This is totally incorrect. The only ones with the power to change the code are the people running the code. If the core developers release new code and they're the only ones running it, they haven't changed the system. Alternatively, if somebody else makes a fork of the code and all of the big miners start running the forked code then the system can change without the (old) core developers having any say about it. The system emerges from the fact that all of the miners are running the same code. There's a good chance that this debate will actually end in a fork, which might not be a bad thing in the long term.
I like the idea of increasing block sizes, but there's an interesting arguement against it that TFA didn't touch on at all. Basically there's a camp of people who feel that the blockchain should be used as a store of value, and a means of exchange for large sums, but not as a means of exchange for small payments. In this view, small transactions should be handled by centralised third parties and kept off of the blockchain. A centralised payment handler can process internal transactions (transactions between two users of their service) without touching the blockchain, and can do external transactions (ones which involve another trusted centralised payment handler) by keeping a running tab of which payment handler owes which what, and periodically settling the score on the blockchain proper. Some of these straw-men go so far as to argue that Bitcoin's inherent non-reversibility is a detractor for most end users, who would really prefer to have a company like Coinbase or Paypal coddling them with refunds (instant verifications are another, less controversial upside of off-chain transaction handling).
I don't like this view of the blockchain's future. I like the idea of a huge, sprawling blockchain that everybody can throw arbitrary data into willy-nilly. I think there are a lot of interesting, censorship-proof applications for such a blockchain. That being said, I don't think it really matters which way Bitcoin goes. Bitcoin is just one cryptocurrency now, and if bitcoin miners don't want to increase their block sizes I'm sure that Syscoin [syscoin.org] or Viacoin [viacoin.org] will be happy to oblidge us (both of these currencies are built around a blockchain that encourages developers to build on top of it).
(Score: 0) by Anonymous Coward on Wednesday May 20 2015, @05:47AM
The real problem it the total chain size, and bandwidth. Its been so long since I synced by bitcoin node to the network because it uses dons of space and bandwidth. Every user of the system has a copy of every single transaction ever made, and needs fast access to a lot of it. That does not scale. Sure its nice to have your 0.01 cent microtransaction in the block chain, but having every user store a copy of that and validate has real cost. There are reasons there are limits on sizes here: one megabyte every 10 minutes for many years adds up too fast already.
(Score: 3, Insightful) by JNCF on Wednesday May 20 2015, @02:02PM
I don't think that every end-user needs their own full copy of the blockchain locally stored. You can store your private keys offline but use public APIs (accessed from a different computer) for queries and transaction propgations. A signed transaction can be safely propogated to an untrusted Bitcoin-peer without worrying about it being tampered with. Queried data could theoretically be wrong, but it would be ridiculously difficult to forge if you wait for a decent number of confirmations (new blocks hashed after the relevant block) and verify that the last, say, 10 blocks were all based on each other and of a decent size. I've never actually bothered to, but I could see doing it if I were engaged in some large transaction and wanted to be sure that the funds were definitely sent to my address. I keep the testnet chain stored locally, for reasons, but mostly just use APIs for transactions. The blockchain doesn't need to be on every smartphone. Miners seem to still have plenty of incentive to keep storing the blockchain, and that's all we really need.