Bitcoin transaction processing takes up to 10 hours
coindesk.com
coindesk.com
To say that centralization increases dramatically at 2 MB just isn't the case. Once people stop running full nodes because they don't believe in Bitcoin's potential as a transaction network then what? This is all about control, who gets to control the fate of the Bitcoin network, and right now that battle is being waged between large well funded companies each of which has its own vision for what Bitcoin is.
Development should under no circumstances be centralized with one entity, but there you have it. The only people who benefit from bitcoin being unable to scale are those who want it to simply be a digital gold / store of value, and those that sell alternative solutions for various markets. This is just going to lead to capital flight from Bitcoin into alternative networks that have a growth potential despite being inferior at the moment.
The only real issue we're experiencing is due to broken wallets that don't handle fees well. Fortunately, most modern wallets today do handle fees properly, and users are slowly moving away from unmaintained wallet software that don't (the main culprit being blockchain.info's wallet).
The median time for fee paying transactions to get confirmed has been 12 minutes at peak [2] (note that 10 minutes is the average time between blocks, and so the absolute minimum possible average time for the first confirmation), which shows us that the majority of transactions are being conducted using proper wallet software which does not cause delays.
In reality, actual bitcoin-using customers that are detached from all the drama in the online bitcoin community don't actually experience any degraded service or delays (again, except for these using broken wallets), and would be very surprised to learn about all the drama going on.
> Development should under no circumstances be centralized with one entity, but there you have it.
Bitcoin Core is not really an "entity". It is a diverse set of technical experts working on improving Bitcoin using a consensus-driven decision making process. There are hundreds of contributors from various backgrounds, associations, and geographical locations. Communication and discussions are all being done in the open, in mailing lists, GitHub and IRC. There is no hierarchy and no one is in charge, and community members have repeatedly shown their dedication to the consensus-driven approach and opposition to merging controversial changes. This development process has made Bitcoin very resilient to hasty decisions driven by populism, political forces and tyranny of the majority situations.
> those who want it to simply be a digital gold / store of value
Straw man? I'm not sure who you're referring to exactly. There are people who want bitcoin to scale using on-chain capacity, and others that want bitcoin to scale using a multi-layered system with the blockchain as the settlement layer and payment channels acting as a write cache. I'm not aware of any group of people that don't want it to scale at all.
If anything, I would say that these advocating for a multi-layered system are more true to the original vision of bitcoin as an "electronic cash system". Using a write cache would allow for really instant (safe zero-conf), really micro (down to tiny fractions of a cent), really low-fees (approaching zero) and really high-volume (orders of magnitude more than what's possible using blockchain alone) payments -- basically, what bitcoin has always been sold as, but never actually was.
[0] https://bitcoinfees.21.co/
[1] https://bitcoinfees.github.io/
[2] https://blockchain.info/charts/avg-confirmation-time?timespa...
People can accept more risk by allowing transactions with fewer confirmations. But you are never going to get under 10 minutes on average (actually, since the difficulty only updates occasionally, when mining power is coming online fast enough it can go under 10 minutes average for a while; or a bit over if miners go offline).
Bitcoin is not, and never has been, designed for instant authorization. You cannot get global, cryptographic consensus in seconds. Credit card authorization can work by being much more centralized.
If you want fast confirmations of small transactions, you need to use something other than Bitcoin. What Bitcoin is good for is unstoppable bulk transfers of value across potentially unfriendly jurisdictions. It's better thought of as a better alternative to a wire transfer than an alternative to credit cards.
Most wallets have terrible protections against doublespends. They're so bad that many don't even warn you after you've been doublespent: https://petertodd.org/2016/are-wallets-ready-for-rbf
Since it hasn't been included in a block, it's not considered to have really happened yet. You could send out another transaction with a higher fee, sending the coins back to a wallet you own, and a miner could see that and decide to take the transaction with the higher fee over the lower one.
One thing that is preventing that from happening too much right now is that the default bitcoin software will refuse to relay transactions of coins that it has already seen, even if they have a higher fee, so it can sometimes be hard to do this in practice. But there's nothing that says this must be the case, in fact early versions did allow later transactions with higher fees to supersede older ones, and they are planning on re-introducing this feature as it will allow people to increase fees on stuck transactions if we start hitting the block size limit and transactions with lower fees start getting dropped by miners.
Or, even without this, you could have sent out two transactions simultaneously, one to the restaurant and one to yourself. If you happen to know which node it is that the restaurant is using (or at least figure out which nodes are topologically closer), you can send one transaction in that direction, and another to the rest of the network, and have a good chance of the one that sends coins back to yourself being the one that actually gets mined.
There is a paper[1] which analyzed the security of the Bitcoin protocol in the case where block propagation delays would be non-negligible compared to the time between blocks. To summarize, this leads to waste of hashing power when blocks are created in parallel and orphaned, thus reducing security.
That paper also proposed the GHOST protocol to fix that problem, by allowing (non-conflicting) orphan blocks to contribute to security and even rewarding such blocks. Theoretically this would allow for 12 second block times. The ethereum devs then implemented it[2], and they have it at 17 seconds now.
Of course, if you need the same amount of certainty as provided by the hashing power currently behind one bitcoin block, then you'll still need to wait for multiple fast blocks to match that. The advantage is when your need for security is somewhere between zero-conf and 1 bitcoin block; faster blocks then provide finer granularity.
[1] https://eprint.iacr.org/2013/881.pdf
[2] https://blog.ethereum.org/2014/07/11/toward-a-12-second-bloc...
Also, note that zero-confirmation transactions could still be relatively safe for low-value transactions, you don't always need the strong guarantees provided by confirmed transactions. Dealing with zero-conf does require some risk management, though.
Finally, as I mentioned near the end of my previous comment - a write cache based on payment channels is currently being worked on, and will eventually provide us with real instant payments (which are also final and non-reversible, but with a deferred settlement).
The settlement doesn't happen for about 5 days although your bigger acquirers may settle daily, and chargebacks are possible up to a month after that. The difference between credit card networks and the bitcoin network is that the credit card network will guarantee the payment to the merchant/acquirer provided they follow the rules of the network.
In Europe, it is already somewhat common to make online purchases with bank transfers (I built my PC this way). In that case the actual non-reversible transfer of funds takes 1 business day by law. There are no fees involved, which is what makes it attractive.
If by confirmation you mean actual non-transferable payment, then it is about 30 days for credit card. If by confirm you mean "probably going to get paid, because of insurance" then yes, that happens in about 10 seconds. There is a big difference between the two, as many of the merchants in the US who have not yet shifted over to EMV are finding out.
12 mins for your transaction to confirm globally has always been the case with Bitcoin. Neither camp is trying to change that.
That's a bit dishonest. The majority of the main core team works for a single company. There is very little diversity.
Of the top 20 contributors by LoC [0], only 4 are associated with Blockstream [1]. Of the 7 maintainers with commit access on GitHub [2], only one is associated with Blockstream (while two are Classic supporters!). The lead developer, Wladimir van der Laan, is not associated with Blockstream in any way. Of the hundreds of contributors over the project's lifetime and tens of contributors on an ongoing basis, only 6-7 are associated with Blockstream in total.
It's also worth mentioning that Blockstream was founded by several prominent Bitcoin Core developers that have been around for years and have a very strong track record. They raised funding in order to contribute to the open Bitcoin ecosystem and work on low-level Bitcoin infrastructure [3]. It's not like some company popped out of nowhere and started hiring Core devs.
[0] https://pbs.twimg.com/media/CZ1q0qaUYAAl_wh.jpg:large
[1] https://www.blockstream.com/team/
[2] https://github.com/orgs/bitcoin/people
[3] https://www.linkedin.com/pulse/20141117154558-1213-the-futur... Reid Hoffman (co-founder at LinkedIn), one of their investors: "Blockstream itself will function similarly to the Mozilla Corporation. Here, our first interest is maintaining and enhancing Bitcoin’s strong open ecosystem. And the structure we’ve chosen will give us the freedom and flexibility to prioritize public good over returns to investors."
Edit: Yes, the multilayer approach with Bitcoin as a backbone makes sense.
No one is saying that. Core's SegWit proposal also gives us an effective blocksize of ~2mb, the same as Classic - only without requiring a coordinated network-wide upgrade and without the risk of splitting the payment network and currency in two if everyone doesn't upgrade in time. This is the more responsible way to deploy such an upgrade, especially if you consider the capacity bump to be urgent. (a safe hard-fork would require a grace period of 6-12 months to wait for everyone to upgrade, and so would be much slower to roll out than SegWit)
Also, several of the Bitcoin Core members have committed to coding an hard-fork proposal for raising the block size limit within a few months, and to bring it up to the wider development community to gather consensus.
I do agree that this isn't about the technical issues, but about control. The bitcoin development community has been very responsive and insightful throughout the scaling debate, and has provided us with great technical solutions to some very difficult problems. The ones opposing the Bitcoin Core development community seem to disregard the technical merit of their proposals in favor of repeating personal attacks, conspiracy theories and toxicity. This is creating an hostile environment that developers will start running away from... which is a shame, because we don't really have any developers to spare - people with intersection of the domain knowledge required to work on Bitcoin (cryptography, distributed networks, game theory, economics, computer science, etc) are VERY rare.
If that is such a huge concern then why is core proposing a hard-fork to change the way the difficulty is adjusted? [0] If they are for adjusting the difficulty computation why not raise the block size at the same time?
[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016...
Core has offered a solution, but only 6 months after another equivalent solution was made and basically deployed...
1. https://github.com/bitcoin/bips/blob/master/bip-0125.mediawi...
2. https://github.com/bitcoin/bips/blob/master/bip-0144.mediawi...
The second is being implemented as a soft fork, while a block size increase would be a hard fork. Soft forks have been done many times while hard forks have no precedent. Why do you consider that a bigger change? Soft forks are "optional", a backwards compatible change, while hard forks aren't.
The problem with SegWit is that it isn't ready. A few days ago, SegWit caused testnet to fork. The cause has been identified and fixed, but it will still be months before SegWit is trusted enough for production use.
While Bitcoin has never had an intentional hard fork, it has had an accidental one.[1] It was chaotic, but not world-ending. In contrast, Classic requires 750 out of the last 1000 mined blocks to trigger, and it has a month-long grace period before accepting larger blocks. It would be a well-known and predictable switchover.
Individual merchants shouldn't be accepting zero conf anyway without risk assessment (it's been demonstrated how easy it is to double spend well before RBF), and if they use an external company to accept then that company will check for the flag.
Re 75% is enough: remember the fork that happened just last year on a soft fork with 95%?
I mentioned RBF as an example of Core adding complexities when they should be focusing on scaling. We can reasonably disagree as to whether RBF's advantages outweigh its disadvantages. I lean toward, "Not worth it." but debating RBF gets away from my main criticism of Core: That they are not being careful or conservative. They're just doing a terrible job of scaling Bitcoin.
RBF helped the existing problem of transactions never going through. A fee market will need to develop eventually anyway (as nullc has said, there's an unlimited amount of data people would like to store for free), and allowing fee changes for transactions where zero conf acceptance is not required is a step towards making transactions easier in a fee market.
Claiming that RBF is not careful is something I can't agree with. If wallet designers disregard a feature of Bitcoin that's been there from the beginning, and users accept zero confs without doing basic security checks, protecting them isn't more important than providing features to everyone else. First seen was never advertised as secure, and if you're too lazy to check for that flag I don't really care. Considering that double spends were still very possible previously, and the detection is one line of code, I'm not particularly worried. https://petertodd.org/2016/are-wallets-ready-for-rbf points out that none of the top wallets would detect a regular double-spend even without RBF.
You keep coming back to RBF, but it seems we only disagree on the magnitude of the disadvantages I highlighted, not their existence. The post you linked to shows that wallets really aren't ready for RBF. The author (who I now notice is a Bitcoin Core developer) is rather disingenuous. He neglects to mention that:
• Without RBF, zero-conf double-spends have a success rate of around 50%. With RBF, this becomes a ≈100% success rate.
• Without RBF, the success rate of a zero-conf double-spend decreases over time. As more nodes see the transaction, fewer will accept any future double-spend. With RBF, the double-spend success rate stays close to 100% until there is a confirmation.
Again, reasonable people can disagree about whether RBF is good or bad. I only brought it up as an example of Core introducing complexity that is, at best, tangentially related to scaling.
Commits 48, files changed 103
https://github.com/bitcoin/bitcoin/compare/0.12...sipa:segwi...
Commits 27, files changed 71
I'm a bit too lazy to count lines now, but I believe nullc has said the actual changes in segwit are smaller than those in the hardfork to 2MB.
Could you point me to the metric by which Classic's changes are smaller? Maybe some of those commits shouldn't be counted or something, or they change less lines, I don't know?
Click on "Files changed" for line count stats. You'll see the Core → Classic diff is smaller than the SegWit diff: +1,803/-339 lines vs +2,193/-386. That's despite the fact that Core → Classic includes:
• Replacing every instance of "Core" with "Classic" and updating all links to online docs, chat, etc. (This is why 103 files were changed.)
• Updating copyright notices.
• Adding a description of Bitcoin Classic (and how it differs from Core).
• Adding a Debian package builder, including a default bitcoin.conf, service description, and pre/post install/uninstall handlers.
• Adding the Classic team's package signing keys.
The functional Classic diff is this changeset[1]. It's +865/-75, and the majority of the lines added are test cases.
1. https://github.com/bitcoinclassic/bitcoinclassic/compare/045...
Does the code you linked to compile and work alone? If so, I'd have to agree that it's smaller. I found the post I was referencing earlier, btw, at https://np.reddit.com/r/Bitcoin/comments/3vurqp/greg_maxwell... That was before the classic code was released, though.
Code committed less than a month ago can hardly be called "ready today". In what sense is classic readier than segwit?
In the comment you linked to, Greg Maxwell is trying mightily to paint a rosy picture of SegWit while disparaging a block size increase. As the diffs show, his assertions on the complexity of these changes are simply incorrect.
> Code committed less than a month ago can hardly be called "ready today". In what sense is classic readier than segwit?
When it comes to reliability, time since commit doesn't matter nearly as much as testing, code reviews, and the complexity of the change. There are several senses in which Classic is more ready than SegWit. The Classic switchover has been run on testnets without issue. In contrast, SegWit's testnet had forks as recently as a few days ago. Thousands of people are running Classic in production right now, including companies like Coinbase. SegWit won't be production-ready for months.
The comment was before those commits were made, so it may have been correct at the time of posting.
Lastly, I hope this back-and-forth has given you a better grasp of the subject and caused you to change your mind on some things. I can't shake the idea that you're trying to convince others rather than figure out what's true. And judging from recent comments on HN, you seem to be overconfident in your technical abilities (not knowing how to use GitHub, thinking HTTPS is too resource-intensive for many applications, etc). I urge you to be more self-critical in the future.
I don't see why not knowing how to check the line difference in github implies a lack of technical skill. The claim about https I had taken directly from a site which claimed they didn't host it on https because it was too expensive. I haven't dealt directly with testing https on a large scale, but again, that's hardly a core technical skill, except for someone running webservices.
I've changed to a bit more uncertainty on the difference between soft forks and hard forks based on someone else's comments here. I'm not sure if I've changed my mind on anything due to your comments in particular (except that the classic fork is indeed smaller).
I'm not sure what I can do about incorrect information from an unreliable source that I'm not aware is incorrect. Do you have any practical piece of advice on that besides "be more self-critical"? (Because the practical consequence of such self-criticalness would be less posting on subjects I'm semi-confident about, and while I'm occasionally wrong, I think I'm overall contributing in a beneficial way. I wouldn't have >2500 karma here if I wasn't.)
Nor are soft-forking changes meaningfully more limited in scope than hard-forking changes. Soft forks, by introducing new rules referring to data unreferenced by the old rules, can be used to make almost arbitrary changes to the protocol. Bitcoin Core's planned implementation of segregated witness uses this technique, which is how it is able effectively to loosen the constraint on block sizes. The technique can be extended to implement an arbitrary increase in the blocksize as a soft fork [1], or even to change the rule that limits the final supply of bitcoin to 21 million units [2]. Name a change you want to make to the consensus rules: chances are that with enough cleverness (and a willingness to make a big enough mess) you can find a way to implement it as a soft fork.
The most salient consequences of changing consensus rules by soft fork versus by hard fork, to my mind, are that (a) soft-forking changes ordinarily introduce substantial additional complexity compared to effecting the same change with a hard fork, and (b) developers can introduce changes via soft forks without having to secure the same degree of explicit consent from miners and users that hard forks require.
Phenomenon (a) occurs because soft-forking changes must be implemented by roundabout mechanisms that preserve formal (but not semantic) compatibility with the old rules, whereas hard forks provide the freedom to make changes in the simplest or most technically appropriate way. Point (b) perhaps helps to explain the preference of Bitcoin Core's team for soft-forking changes: they are less constrained by the desires of users and miners under a policy of implementing changes to the consensus rules by soft fork than they would be if they were to attempt the same changes with hard forks.
0. https://medium.com/@octskyward/on-consensus-and-forks-c6a050...
1. https://bitcointalk.org/index.php?topic=1296628.0
2. https://np.reddit.com/r/bitcoin_uncensored/comments/43w24e/r...
Edit: I encourage interested readers to verify what I have written by referring to the sources I cited or by doing their own research. Downvotes in discussions of Bitcoin here unfortunately tend to reflect the voters' loyalties in the blocksize brouhaha more than their honest assessment of whether a comment is informative and correct.
Core prefers soft forks because they're less risky, and don't require all users to upgrade, only minors.
For this reason, some people view soft forks as insidious in a way that hard forks are not: the sole purpose of a Bitcoin node is to interpret data contained in the blockchain and in newly broadcast transactions to determine the validity of those transactions under a particular ruleset, and a soft-fork is a subterfuge specifically designed to make some of those nodes unaware that their ability to perform that function has been destroyed.
If soft forks are "less risky", it is precisely for that reason: soft forks ensure that the nodes of miners and users who do not explicitly consent to a rule change fail even to notice that the rules have changed!
Second, soft forks have been the standard since the beginning, and everyone understands that minors can set their own rules.
Third, non upgraded nodes, if they follow the longest chain, do not break. If they mine themselves they'll get orphaned, but that doesn't break them as long as they wait for a couple of blocks before accepting transactions as valid.
Fourth, soft forks have traditionally repurposed non standard transactions, which shouldn't be issued by anyone expecting consistent behavior. Segwit uses anyone-can-spend which are non standard, and as the bip says "Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion."
Fifth, anyone can "notice" by virtue of the block header changing. A majority of minors can reject transactions, that's not deceitful in any way.
Some of those changes seem like they'd require users cooperation as well, though. The "meaning" of the extra data would only be useful by those that decide to acknowledge it.
I'm wondering if it might be a better idea in general to do all future changes as soft forks. Is anyone arguing this?
The current attempt by Coinbase to force a contentious hard-fork is dangerous. There are many people that even question its requirement, let alone whether it can be done safely.
I'm not saying it's not going to happen, but it isn't going to be done quickly, and if it is finally going to happen, it'll be managed by the core developers.
This is not the technique that segregated witness uses. All SegWit transactions are on-chain transactions that are visible to existing clients, which means that the coin cap and all the other Bitcoin rules still apply and the coins from them can subsequently be sent to non-SegWit clients - the only thing that's not available to older nodes is the information about who's allowed to spend SegWit transactions. It's similar to the P2SH fork a few years back in that respect. (That's also why the effective block size gain is limited. Any further increases are planned to be done through a hard fork.)
Now, technically of course 51%+ of miners could refuse to accept standard Bitcoin transactions of any kind and force everyone onto their extension chain. In fact, they could even declare a day zero after which they refused to accept any existing transactions or coins as valid, resetting the whole thing as an extension chain. This is an unavoidable consequence of miners being able to decide which valid transactions they accept - Bitcoin simply relies on the majority of miners not trying to shut the whole thing down.
No, segregated witness doesn't change the semantics as drastically as, say, changing the effective cap on the final supply of monetary units. But that's beside the point—which is that it is wrong to think of soft-forking changes as intrinsically less significant or more acceptable than hard-forking changes. You can effectively change anything with either approach. To judge a change to the consensus rules, you must look at its semantics: whether it is implemented as a soft fork or a hard fork tells you essentially nothing.
Yet a large chunk of the Bitcoin community seems to believe that soft forks should be preferred to hard forks as a matter of principle. That is nonsense.
1. There isn't a segwit supermajority or
2. It's longer by very few blocks, perhaps only one
In the first, nobody should be using segwit to send money and therefore there's no breakage, and in the second the threat isn't increased that the threat of any orphan block, which happen occasionally. If you're accepting single-conf then you're accepting the risk of orphan blocks, so this isn't worse.
Seg. Wit. is complex but not optional. It means you can simply ignore it.
It's also not even a soft fork, just a policy change for minors. It was in the original release of Bitcoin and removed for DoS reasons that no longer applied. Some minors had been running it previously.
It's also opt in. I fail to see any reasonable way in which a blocksize increase is "comparatively trivial".
The big spike seems to be over, anyway.[1] Median time never exceeded 13 minutes. Note that this does not include no-fee transaction requests. There may be an attack underway which involves lots of tiny transactions that may never clear. One of the purposes of the fee is to discourage such spamming.
[1] https://blockchain.info/charts/avg-confirmation-time?timespa...
Is the market efficient in the technical sense? Is it as useful as it could be in the human sense? I wouldn't be surprised either way of the answer to the first question, but i'm pretty sure there's a whole 'lotta people who think bitcoin would be more useful to humans if the block size were changed.
While this drama affects transaction times and scalability, it doesn't fundamentally change the supply/demand curve. Transactions offering the highest fee get processed first and rising demand (of transactions) with stable supply (of processors) raises prices like it should.
A non-free market would be something like if Core developers' transactions got moved to the front of the line regardless of transaction fee.
I think your example of a non-free market would better be called unfair. Of course, everyone has a different definition of fairness, but it's a useful term for discussion to coalesce around.
The protocol itself has to be upgraded, and majority has to agree before we can mine bigger blocks.
People talk as if there is a Bitcoin conspiracy where some central entity decides all things Bitcoin-- where blockstream is the equivalent of the illuminati. If someone thinks they can do a better job then go fork the source and convince everyone else why it's better.
Consensus aside, this is a lot harder said than done. one of the reasons btcd is not widely adopted, even though it's purporting to be 100% compliant with core, is that there is no formal definition of what that even means. to be 100% compatible with the bitcoin protocol is to be 100% compatible with core - bugs and all. the community needs an RFC like paper describing in details what 100% compatible means. Then we can safely run other nodes without worrying that we'll get screwed by not having the same bug as core for example.
I'm not one to believe in conspiracies or even subscribe to the thinking of core==blockstream. But I don't think you'll disagree that what goes into the consensus protocol is under control of the 5 maintainers
The consensus protocol is dictated by exactly that, consensus, not this allegedly omnipotent cabal.
Miners are a different story though; understandably, they're very reluctant to change (who would with so much money on the line). It is also unfortunate how miners switch back and forth between classic and core so quickly.
We can't do anything with those three examples, and Bitcoin, until a consensus agrees and actually does something due to our usage of them as centralized in practice. That's an immediate disincentive, and likely deal-breaker, to improve as has been demonstrated by literally five decades of history. E-mail is long due for some defenses against spam, but we literally cannot. The Internet is due for a rethink on its architecture, but we literally cannot. Spam, source filtering on network egress, DNS security, and IPv6 adoption are four examples of problems that we've had for multiple decades with the aforementioned protocols and cannot remotely begin to address because of the barrier of individual work within a decentralized protocol or system creating an economy of incentives. It takes the worst part of software deployment itself (outliers running old versions) and then makes it even worse (administrators need incentive and/or consensus to upgrade said outliers). Momentum is already a bitch to deal with in traditional software, and decentralization accidentally gives momentum a frightening amount of power.
Bitcoin is just demonstrating all of this on an accelerated timeframe, and it's worth thinking about when discussing the benefits of decentralized systems. The Bitcoin block size is simply its IPv6 moment, and look how long we've been in dire mode on IPv6. Yes, Bitcoin is decentralized (yay!) but everybody uses a centralized blockchain (well...) and just papers over that fact. Seriously, the very concept of a blockchain split undermines the description of Bitcoin as a decentralized protocol, because it requires out-of-band resolution. Who are the out-of-band resolvers? The centralization.
I watch all the improvements to these systems try, and fail, and I cannot help but wonder why people still try to make decentralized systems when usage patterns almost always make a system centralized (IRC: decentralized chat; networks: centralized. IP: decentralized routing decisions; Internet: centralized). Then the FLOSS crowd tries to decentralize big centralized systems (identi.ca, GNU social, "pure" XMPP and so forth, most of which amusingly have a "centralized" option) and wonder why nobody uses a system that starts with "step 1, become root," which is a slightly different issue but related.
Decentralizing a system is one of the worst decisions you can make if you expect the usage thereof to be centralized in nature. You're dooming yourself or, far more likely, those begrudgingly after you to supporting the choices you made in the first version for a long, long time (despite what you tell yourself while writing it), and you need to think about every single decision long and hard. And then you'll still get it wrong because you cannot predict the future. Don't get me wrong, I love the spirit of decentralized systems, but I've been sitting here since I started this comment trying to think of an example of it going right. Still trying.
Perhaps it's time to objectively look at decentralization itself. I might be wrong, but it seems to keep shooting us in the foot and making beds we have to sleep in, often against our will. Maybe there's a different means to accomplish the grand decentralized vision without the problems I've touched on here; I'm aware of the benefits of distributing authority, and I wish we could advance decentralization to a place where bummers like this don't happen, but I don't know how.
(Also, not trying to be negative, nor am I criticizing Bitcoin. Just stepping back and observing in general, and I did write this comment with the context of many things I mentioned succeeding despite the problems decentralization brings.)
I'd take slight exception to this:
> Seriously, the very concept of a blockchain split undermines the description of Bitcoin as a decentralized protocol, because it requires out-of-band resolution. Who are the out-of-band resolvers? The centralization.
Well, in the original architecture as proposed, each individual user - or at least every fullnode operator - is also a miner. So there "should be" something like 5000-10,000 miners by now (based on current numbers of miners and fullnodes) none with much of a hashpower advantage over the others.
In that environment, conflict resolution would - could only - move forward in a "one man, one cpu, one vote" fashion, with "majority rule" controlling the blockchain.
The task is not to make a magic free-floating decentralised system, but one which is resistant to getting central points lopped off or controlled. For that look at bittorrent, or even DNS. Whenever the US government has flexed it's muscle, trying to assert control over DNS, other countries have threatened to make their own DNS root and the US has backed down. Anyone can run a DNS root, but that alone doesn't fix the problem, it takes people actually using that fact to prevent centralisation. Bitcoin is stuck in a place where the vast majority of users have to agree to a change before change can be made.
It's a broken market, one in which the supply of space in the blockchain is unresponsive to increases in price induced by higher demand.
This impasse over block sizes and Bitcoin's governance would never have happened if Satoshi Nakamoto had designed the protocol well in this respect. It's unfortunate that nobody seems interested in fixing the basic problem, which is arbitrary parameters trying to do the job of endogenously determined economic variables.
TL;DR microtransactions discouraged on BTC blockchain? What's the problem?
There's no benefit for the overhead. This is an argument against using bitcoin.
This is basically the same as the nightmare scenario anti-2MB people describe with more centralization. By refusing to fix the protocol you are going to end up with a scenario where small players cannot participate in the block chain.
It seems everyone wants to believe so hard bitcoin is the currency you'll buy bubblegum at 25c with, maybe it's more the coin you use for 100s$ type transactions rather? What would be wrong with embracing using other chains? I fail to see anything short of a dynamic altcoin ecosystem to keep the required pseudonymous/microtx/decentralised characteristics alive.
I mean bitcoin is great and all but it can't be everything to everyone and that's okay. Let the 'real world' interface on BTC, and we'll interface BTC to what we actually use. As always.
The issue your parent comment describes isn't an issue of just usability though, but of market control. If you push out people who can't afford large transactions then you eventually have currency owned and controlled by the few who can afford it. Hardly the original vision of bitcoin.
But for everyone else, if I can't buy lunch with it due to high transaction cost then I have no interest in storing any wealth in it either, money is useless if it isn't usable.
So if it isn't a currency for buying lunch, and it isn't a currency for storing wealth, what the hell do I use bitcoin for? Pretending to play daytrader at the foreign exchange?
Do you not see how having major actors in the network is good for liquidity? If you use it as medium of exchange mostly, you're fairly isolated from price tampering from the rich and mighty.
We've been functioning like this for quite some time now. Risks from exchange value falling or physical exchange robbing you are close to nil if you manage your inventory and trades appropriately.
I don't accept your dismissal about conflation. If the tx-validation is centralized, the distribution and intentions of the actual users makes little difference to the potential for misappropriation of the network behaviour
Any system that requires users to hold various different forms of money for various transaction sizes is doomed to fail to a single money that scales to essentially any transaction size or frequency. A single currency that can solve both micro- and macro-transactions will easily dominate a system of different kinds of money.
However, if fees hit the $0.30 and up range they stop losing their competitive edge against credit cards.
If consumer retail on the Bitcoin blockchain isn't a concern for you (as it doesn't appear to be for Bitcoin Core), then high fees aren't an issue. If consumer retail is a use case you want for Bitcoin, fees need to stay low to offset Bitcoin's other disadvantages against credit cards.
That being said high fees don't negatively affect the main retail use cases Bitcoin has demonstrated the best suitably for: cryptolocker payments and contraband.
> as it doesn't appear to be for Bitcoin Core
Source?
Core has shown a very promising roadmap for scaling the bitcoin network. This includes SegWit, which gives us a 170%-400% capacity bump without requiring a network-wide upgrade (at the risk of splitting the payment network and currency in two if everyone doesn't upgrade in time), work on IBLT/weakblocks to improve network propagation times and bandwidth usage, and research on compressing data more efficiently [0]. Several of the Bitcoin Core members have also committed to working on an hard-fork to raise the block size [1], propose it to the development community and try to build consensus around that.
In addition to that, Blockstream, which was founded by a few of the core developers, is funding work on Lighting Network, a write-cache for bitcoin transactions based on payment channels, which would allow for scalable, instant, nano, near-free payments.
[0] https://bitcointalk.org/index.php?topic=1377298.0
[1] https://medium.com/@bitcoinroundtable/bitcoin-roundtable-con...
I was making an inference but one it seems Gavin Andresen agrees with:
"Over the last year of trying, and failing, to reach a reasonable compromise, it has become clear to me that some developers don’t want any on-chain scaling solution any time soon. [goes on to reference Lightning]" http://gavinandresen.ninja/satoshi-roundtable-thoughts
They do. Hugh fees per tx bite means higher cost for multisig transactions. All on-chain market already use some sort of multisig setup, including legal ones such as OpenBazaar.
Furthermore, this high cost also makes both metacoin protocols, timestamping services, as well as oracle services (smart contracts) very costly.
Therefore, they work by either shrinking the market size for bitcoin, or by determining which transactions are simply dropped.
Neither are things that people seem to want.
Most people want blocksize increased, relieving competition for miner time and thus requiring smaller fees per tx. However, Bitcoin's design failed to anticipate that hashpower would become so centralized and that so few bitcoin users would be contributing hashpower. Essentially, this means that a handful of miners that have secret, proprietary hardware control the fate of the network and that average users have very little representation, even if they're wasting their own compute trying to chip in as a miner.
At some point, the network will stop awarding new coins to miners as blocks are found. Then the only incentive miners will have is transaction fees. That's scheduled for something like 2021 or 2022. This blocksize controversy is a good preview of what we'll see when that happens.
I'd be interested in a source on this. It seems like more transactions with smaller fees could be just as valuable as fewer transactions with higher fees to miners.
Miners also get to choose which transactions to include in a block, so even if there are nodes which accept 2 MB blocks miners can choose to only include the most valuable transactions and influence the fee market that way.
I don't have a source. It'd obviously be against the political interests of the mining cabal to admit this so frankly. This is my opinion on what the statements of anti-BitcoinXT/BIP101 people actually mean.
>It seems like more transactions with smaller fees could be just as valuable as fewer transactions with higher fees to miners.
Since the transaction volume on the network is now exceeding what can be included in a 1MB block, some transactions have to be left out. Miners prioritize txs with higher fees attached. This creates the incentive for people to include larger tx fees so that their tx is more likely to be included in the next block.
If the blocksize is increased and more txs are processed but each tx continues to have just a token tx fee, then no, they don't make more money. There is little reason to include a non-nominal tx fee if the network's volume doesn't exceed the blocksize (at least not until the network stops awarding new coins). Keeping the blocksize artificially small constrains the availability of miner time, thus requiring users to pay more to get access to it.
it most certainly is not. regardless whether you agree or not with the current blocksize debate, it is undeniable that the supply of blockspace is under the centralized control of the bitcoin-core developers. That's just a fact.
You don't need Bitcoin core's permission to run classic or XT, just go run it. You're not going to be thrown in jail. And convince the miners to run it too. Others have tried and haven't been successful not because of core, but because the majority isn't convinced that the potential advantages outweigh the disadvantages at this point in time.
Or maybe I'm naive and there is some small block conspiracy that runs the show.
What I'd love to see is if core would simply stop all development (maybe after the HF and SigWit) and focus 100% on developing an RFC describing the protocol (bugs and all) in detail. Once that's done then we can feel comfortable running other nodes that are compliant and there can be true competition. Then we can work on a steering committee that can manage the development of the protocol. Because 5 developers acting as economists/central bankers is not the way to go.
XT and classic certainly have different consensus rules from core once their activated, that's the whole point of their existence.
I think you're referencing bip 34, but I don't see how that's relevant.
we are in uncharted territories here and I for one hope core's monopoly over the Eco-system is broken. we'll all be better for it
I have to point out that I'm completely new to this issue and the underlying technology, so pardon me for ignorance.
Yes. And the reason that may be important is for the long term viability of bitcoin.
In order for bitcoin to work, you need a lot of miners spending a lot of electricity to run these hash calculations. That's what will actually ensure the transaction makes it into the blockchain. The incentive for the miner to do so, currently, is that they will "discover" their own bitcoins while doing so, essentially paying themselves for the work.
However, the rewards are decreasing over time and will eventually phase out completely. The long term vision of bitcoin had been for users to specify a transaction fee when they try to buy/sell something (taken from the amount they're sending), which the miners will earn if they figure out the hash.
For now, since there's still new blocks being discovered, the network has kinda been working with minimal transaction fees. But if people will never be willing to pay transaction fees, there's no long term viability here.
Yeah because people got frustrated and gave up.
Bitcoin is starting to look like "decentralization" at its worst. Pretty much the only asset ever in existence that hasn't fallen in price due to uncertainty.
Regarding "the halving", how in the world could you design in a doubling of expenses on some arbitrary date in the future? That didn't make any sense to me.
That said, it is neither - it is a halving of extra reward on top of transaction fees.
I don't have a side one way or another, and I don't own bitcoin. But, it's ridiculous to see these bitcoin 'companies' taking such desperate measures. Given the nature of all the characters I've seen come out of the woodwork thus far, it is not surprising.
Honestly, the whole bitcoin ecosystem is a sinking ship at this point. The protocol is broken and there are too many vested interests to properly fix it. It's time to move over to Ethereum.
Smaller block sizes are better for Coinbase, all else equal, because that means transactions on the blockchain are more expensive. Which makes sending payments on third party services more attractive, and long term they can flip bits around in their database while taking a cut, ala PayPal. Except the backing currency is BTC, not USD et al.
I think that Coinbase is primarily interested here in shepherding the Bitcoin ecosystem as a whole towards success, because it doesn't want the pool it's swimming in to dry up. Sometimes selfless and selfish motivations align.
Ethereum has been a beneficiary of that outflow, but is a significantly less tested code base, with much less hashing power, and significantly fewer users. Its still a very early product with its own vested interests. The two networks aren't even comparable at the moment in terms of capability and ecosystem.
This is fundamentally not at all how bitcoin works. Nobody relies on coinbase to actually use bitcoin. A bigger -maximum- block size won't increase centralization since 1 MB every 10 minutes is so far from stressing even modest resources. Anyone who can watch netflix can download at least 200 times faster than they need to keep up with the blockchain.
They get the mining fees regardless of whether they include your transaction or any others for that matter.
Yesterday it made illegal movies depicting homosexuality or one night stands. Tomorrow it might decide to make bitcoin mining illegal (as it has forbidden some forms of bitcoin trading in the past)
So I'd say, yes China really is a bastion of freedom - just a different kind of freedom than what westerners think. Economic freedom, rather than political freedom.
The tallest valid chain. A chain with block sizes exceeding the max won't be considered valid.
Bitcoin Classic is trying to gain support for a hard fork with 75% miner vote, but in reality this would also require every exchange, wallet and merchant to pledge their support, or risk creating a network split with two separate currencies.
I don't know anything about Bitcoin, so maybe it's just unfeasible.
DDoS - the best weapon of Internet, still undefeated.
The more you mine it, the more it costs. They seem to have a concern about a virtual currency that unlike real ones can prevent some "non realistic" transaction behaviours that are not compliant with the real world.
Transactions are never free. And the bigger a system is the more a a transaction costs.
What frightens me is the High Tech business trying to piggy back on a pretty sane currency and want to influence for their personal interests the system in a way that might deserve the economy globally.
Are all High Tech companies sociopaths just caring about nothing but their private benefits built upon other's works?
That's pretty much how all the world works. Capitalism at it's best.
As a side node, bitcoin is a "pretty sane currency" only in the mind of gold bugs and conspirationists. There's a reason we moved from an inflexible currency (gold) to a flexible one ("printed" money)
Why can't I have both? For example, the taxes the company pays could cover looking after homeless people.
As a former small business owner I know very well how workers and small companies are being put in an unfair competition, especially because bigger companies have de facto monopolies and the support of both administrations and governments to play dirty.
Especially by having hidden subsidies or regulation unfairly protecting their business and weakening others.
I think as someone who was taxed 40% as a worker, 50% as a business owner, I have the right to be scandalized at the fiscal contribution of any so called successful businesses (google, apple, fb, ms, jp morgan ...). Fuck, this is clearly fiscal inequity. What triggered revolution in USA and France.
When competition is not fair it is not a liberal system anymore. And when wealthy kids get wealthy by birth and citizens find it remarkable, I guess people forgot why and how the citizens of the USA created their own country.
USA was despising the priviledge system and wished for a system where every one had a fair chance to compete for their success (except the black slaves).