Hacker News new | past | comments | ask | show | jobs | submit login
Bitcoin transaction processing takes up to 10 hours (coindesk.com)
272 points by elorant on Mar 5, 2016 | hide | past | web | favorite | 185 comments

This is a really complicated discussion, that has been splashed all over reddit and other forums for the last year. The reality is that the network is rapidly approaching if it hasn't already exceeded capacity at 1 MB. This doesn't break the network, but it ends up with load sheddding (people who no longer transact) and worse, people who transact but due to rapidly changing fees have to wait in line indefinitely to get their first confirmation. The mempool will eventually randomly eject transactions, but this can cause issues for wallets and other services.

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.

> To say that centralization increases dramatically at 2 MB just isn't the case.

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.

>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.

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" isn't proposing a hard-fork to change the way difficulty is adjusted, one developer was and he changed his mind after realising this wasn't practical: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016... (Also, that's Luke-Jr who I guess technically counts as a Bitcoin Core developer, but uses his own heavily modified client.)

"Core" is not proposing anything, that difficulty adjustment hard-fork proposal was brought up on the mailing list by a member of the community and is in early discussion stages. There's no consensus that this change is necessary, and there hasn't been an in-depth discussion about how and when it should be incorporated (if accepted) and whether it should be alongside the block-size hard-fork or separately.

That was made by Luke-jr one of the more influential and out spoken developers who is strongly opposed to a block size increase. He's also associated with Blockstream.

But isn't the coordinated network upgrade problem already solved? In the Bitcoin XT (sp?) thing, the solution was to not switch over until over 50% of participants reported being in a version that supported 2MB blocks.

Core has offered a solution, but only 6 months after another equivalent solution was made and basically deployed...

Segwit will increase capacity to 2MB, if and only if all the creator of transactions (wallet, exchange, ...) switch to the new way of encoding. So it is going to take even more time than classic.

The fact is that transactions still consistently and reliably get mined quickly with reasonable fees of 40-50 satoshis/byte [0] [1], or roughly $0.04-$0.05 for an average 250 bytes tx. For a global payment network that provides non-reversible payments and near-instant (within a block) settlement, this is a dirt cheap.

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...

I'm not sure what camp you're in, but for the people who want to use Bitcoin for regular transactions 12 minutes is absurd. It takes a few seconds to authorize and confirm a credit card payment.

The Bitcoin protocol has always had a design that gave 10 minute average time between blocks being mined; which means 10 minutes before you have a single confirmation. It normally considers 6 block (6 confirmations, at an average of 10 minutes each) to be enough to avoid a double spend.

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.

> You cannot get global, cryptographic consensus in seconds.

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...

So what's happening when I purchase something at a restaurant that accepts bitcoins? It usually takes only a 10-15 seconds for them to accept my transaction. I realize that a confirmation on the blockchain hasn't occurred, so with some hackery it's possible to double-spend - but, it's never been a problem.

They're trusting you, much like most restaurants trust their guests to not just leave the table without paying.

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

But clearly something has happened, that they accept as evidence I plan to pay them. How difficult would it be for me to revert that action once I've left?

What has happened is that your transaction has propagated through the network, and some payment processor that they contract with has seen that transaction and confirmed that it has been sent out.

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.

You can't compare the two. A confirmed bitcoin transaction represents the final settlement of a non-reversible payment, and is spendable by the merchant immediately after those 10 minutes. Credit card payments are reversible for a period of a few months (so what you really get is a probabilistic payment, which requires fraud detection and risk management to properly handle) and can take 1-4 weeks to become spendable by the seller.

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).

> I'm not sure what camp you're in, but for the people who want to use Bitcoin for regular transactions 12 minutes is absurd.

12 mins for your transaction to confirm globally has always been the case with Bitcoin. Neither camp is trying to change that.

Depends what you mean by confirm.

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.

> 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.

That's a bit dishonest. The majority of the main core team works for a single company. There is very little diversity.

This is simply not true. Pure propaganda being promoted by XT/Classic supports.

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."

Maybe it was just bad luck but my transaction took 2 days to get confirmed even though I added the standard fee of 0.0001 BTC.

Edit: Yes, the multilayer approach with Bitcoin as a backbone makes sense.

That's exactly the reason why I believe in the potential of Decred.


And how is Decred better exactly at scaling?

It doesn't need to be at this stage. It's better at governance by combining PoW and PoS mining ie. everybody has a saying on what the next block will be. It only remains to be seen if it will fulfill its potential.

This may be a little unpopular here, but I really appreciate the conservative approach by the Bitcoin core team. There's a lot of cryptocurrencies out there and Bitcoin's dominance is from its long history and staying power. Bitcoin needs to have a near majority of agreement for any breaking change or else its risking its own dominance. Hopefully, transaction fees become less over time, but regardless they're necessary to prevent spam. No matter how big of blocks you have, you're always going to have a spam problem and the Bitcoin forks have yet to show how bigger blocks will mean faster transactions.

Except they're not being conservative. Core's approach has been to introduce new complexities such as replace-by-fee[1] and segregated witness[2]. These are much bigger changes to Bitcoin than a one-time increase of the max block size.

1. https://github.com/bitcoin/bips/blob/master/bip-0125.mediawi...

2. https://github.com/bitcoin/bips/blob/master/bip-0144.mediawi...

The first is just putting in code that had been part of Bitcoin since the beginning, temporarily removed due to DoS concerns, and re-added once those concerns had been alleviated by requiring a higher fee.

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 RBF is that (in some cases) it can allow double-spends with older receiving software. If the receiver accepts zero-confirmation transactions, the sender can send one transaction, wait for the receiver to accept it, then send another transaction with a higher fee and a different receiver. In other words: RBF may be opt-in, but it decreases security for wallets that don't support it.

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.

1. https://bitcoin.org/en/alert/2013-03-11-chain-fork

Those types of transactions have been non-standard and non mined by default anyway. The opt in flag has been designated for replacing transactions from day one, and plenty of wallets will recognize it and warn.

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%?


The cause of the fork you mentioned was not related to the threshold. Miners had software that falsely claimed to supported the new, stricter checks. Even if the threshold had been 100% of the last 1,000 blocks, the fork would have still happened. Unless you think no threshold is ever acceptable (because software can lie about its capabilities), your argument proves too much.

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.

I mentioned that fork because you implied that a 75% hard fork would be effectively riskless. There are all kinds of things that can go wrong, and not wanting a hard fork unless there are no other options is prudent.

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.

I'm not sure how you got that impression, but I certainly don't want to imply that Classic's method is effectively riskless. I'm saying that it's the best available option to help with Bitcoin's current scaling problem. Compared to SegWit, it's an absolutely trivial change. Adoption of it is predictable (750/1000 most recent blocks, plus a month grace period), giving everyone plenty of time to update their software. And most importantly, it's ready today. Even the most optimistic timelines put SegWit months out.

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


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?

> 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.

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...

(Not very familiar with github, didn't realize you could count lines so easily).

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?

Yes, that's the functional diff and test cases. It compiles and runs. None of the subsequent commits to Classic fix bugs in that code. It was solid from the get-go.

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.

>As the diffs show, his assertions on the complexity of these changes are simply incorrect.

The comment was before those commits were made, so it may have been correct at the time of posting.

That's giving too much credit. His predictions were incorrect, and not by a small amount. I'm no Bitcoin developer, but a month ago it was obvious to me that Segregated Witness would require far more code than a block size increase. Maxwell thought SegWit would be smaller, but even its current (incomplete) state is bigger by a factor of four. That's not a small mistake. It indicates a fundamental misunderstanding somewhere along the line. The more I read comments made by Core devs, the more I think they are either mistaken or misleading. I truly wish this wasn't the case.

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.

The difference wasn't that segwit got bigger, it was that the other patch got smaller. (Or rather, looking at it again, he's referring to BIP101 which was an adjustable size HF).

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.)

You really shouldn't be accepting zero-confirmation transactions that are marked as replaceable no matter how old your receiving software is. Even though it happens that most pools don't ever actually accept replacements for them, that's merely a policy decision on the part of the pools - the field marking them as replaceable has been there as long as Bitcoin's existed and I think a few pools do honour it.

The segwit soft fork is not optional, clients that do not upgrade in time will be broken much like a hard fork.

If the fork is successful, then the longer chain will always be the segwit one. The only problem is if the longer chain is non-segwit, but that means either

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.

It's not about which chain is longer. With segwit as a soft fork old clients will recognize new blocks as valid but fail to see segwit transactions, effectively failing silently. With segwit as a hard fork old clients will not accept new blocks and fail loudly. In both cases old clients are forced to upgrade in order to keep using the network.

All segwit transactions are valid under the old rules. Old clients can continue sending transactions as they did before, as I mentioned, segwit only repurposes non-standard transactions, so it should have no effect on someone using the network normally.

Your understanding of soft forks is incorrect. Changes to the consensus rules implemented by soft forks are in no way optional, nor are they backwards-compatible [0].

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.

No, you cannot "change the rule that limits the final supply of bitcoin to 21 million units" through a softfork. You can indeed append an "extension record" with "extension transactions" that generate and transfer whatever number of extension coins you like as https://np.reddit.com/r/bitcoin_uncensored/comments/43w24e/r... lays out, but you can never ever convert those extension coins into ordinary Bitcoins that existing nodes accept as valid. You've basically created a very elaborate altcoin as a sidechain of Bitcoin.

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.

Yes, you're right, but again only in a formalistic sense. It is the semantics of the rules that matter, not their form. And the semantics can be changed arbitrarily in the way I described. I don't think my point is pedantic. Segregated witness is just this sort of change, one that preserves the form of the old rules while significantly reinterpreting their meaning.

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.

Optional and backward compatible in the sense that old nodes continue to work and recognize the new block chain as valid.

Core prefers soft forks because they're less risky, and don't require all users to upgrade, only minors.

Old nodes continue to work only in a trivial sense: after a soft-fork, they can no longer properly interpret the meaning of data in the blockchain, so their ability to validate new transactions has been destroyed. If Bitcoin Core's soft fork to introduce segregated witness proceeds, for example, nodes that are not upgraded (and so have no understanding of the witness data) will happily interpret all seg-wit transactions as valid, whether they really are or not.

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!

Firstly, not all soft forks introduce extra data. Some are simply about minor policy.

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.

I do want to thank you for pointing out that many changes can be done with a soft fork, which I hadn't seen before. That got an upvote from me.

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?

I don't know of a single responsible bitcoin developer that wouldn't prefer using soft-forks to hard-forks. Bitcoin has had hard-forks in the past, but they have been done in response to a specific issue, and were done very quickly. What's most important, everyone agreed that the hard-fork had to be done.

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.

I've looked at RBF and my understanding was that it was totally opt-in? Older versions of Bitcoin core still work and can keep on mining. IMO that's less big of a change because it's not breaking anything. I haven't actually looked at segregated witness though.

Both of them are opt-in.

RBF was introduced by Satoshi and not core.

Seg. Wit. is complex but not optional. It means you can simply ignore it.

It's just that the core developers seem to be selective about what they are conservative about. Replace-by-fee, which is a very controversial change which there's never been a lot of discussion about, gets fast-tracked, while a comparatively trivial change in block size gets iced because it is not part of 'the vision'.

There's been plenty of discussion (I remember reading articles about it a year before it was actually committed).

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".

https://bitcoincore.org/en/faq/optin_rbf/ It may be worthwhile to read the detailed RBF FAQ.

It's a free market. If you pay a higher transaction fee, your transaction gets processed sooner. Typical transaction fees are now $0.04.

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...

> It's a free market.

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.

Why is it automatically assumed that higher tx fees are bad? It only disincentivises microtransactions on the bitcoin blockchain. There's nothing stopping anyone from using another coin (litecoin springs to mind) for smaller transactions.

TL;DR microtransactions discouraged on BTC blockchain? What's the problem?

Any fees above $0.01 make microtransactions unlikely. Maybe not a bad thing though.

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.

We're still quite off from $0.30, though. At the peak of the recent transaction flood attack, you only had to pay $0.06 (60 satoshis/byte for a 250 byte tx) for a 90% chance to get including in the upcoming block. Now, that the attack has somewhat calmed down, we're down to the $0.04-$0.05 range, and will probably continue going down over time.

> as it doesn't appear to be for Bitcoin Core


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...

> Source?

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

> 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.

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.

Microtransactions being discouraged on BTC is basically the same as " only big players can afford to interact on BTC "

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.

Well from a casual following of the coin world I'd say the ship has sailed a while ago on centralization. Individual miners represent what, low 2digits percent hashing power?

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.

You conflate people mining with people who could benefit from bitcoin as a uewful currency.

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?

You'd be a fool to store value in it long-term regardless of target tx value. I'd argue it's main purpose is as "middle currency". It has the potential of acting as synchronization mechanism for any two parties arbitrarily across mankind. You buy some with your preferred currency (EUR, LTC whatever) when you need to transact in some context conventional money isn't fit for. The transactor is then in a position where he needs to unload the BTC for his day to day currencies of operation.

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.

Unrelated to my sibling reply

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

> I mean bitcoin is great and all but it can't be everything to everyone and that's okay.

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.

Yeah, I fear the same thing. Maybe we can collectively agree 'not this time'?

The problem is that higher transaction fees don't increase the throughput, they only change priority.

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.

1. People want to use bitcoin for transactions. 2. They're priced out of the market. 3. OMG this us so obvious why am I even...

Yeah but it's not as if there weren't literally hundreds of altcoins with enough liquidity to handle the lower end of the tx value scale

At which point, why is there a need for bitcoin at all?

Well... There isn't, in the same sense as there's no need for specifically the USD in the grand scheme of things, right?

Right. But the reason I use USD is because it's what I spend in. If I'm primarily in an area that doesn't use USD, I would avoid holding USD.

There's no benefit for the overhead. This is an argument against using bitcoin.

I agree with you, its not for everything but there inherent benefits to the bitcoin protocol/platform. Whether these integrate with your use case is (no offense intended) irrelevant to its properties

What's wrong with micro transactions?

It is a market. I don't think the word 'free' adds anything, except to perhaps avoid analyzing why the market has the structure that it does. Changing the block size changes the market. If the market is currently free, would it still be free if the block size were increased? I think yes. There's no distinguished natural market structure for bitcoin, like all markets. What do you mean by free?

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.

Free means there aren't external factors interfering with market dynamics.

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.

Defining a market is itself an external influence. There is no object that is intrinsically a market: all markets are made to exist by human action. Sure, it would be nice that those external factors that define a market don't change too much too quickly, and that those factors are clearly and openly accounted for, but all markets are unfree if this is your definition. It is an ideal that cannot be realized because it is incoherent.

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.

Where do you draw the line as to which factors are 'external' to a market?

Yeah exactly. People could be 'external factors', once you challenge the assumption that Bitcoin is decentralized enough to be free of their influence.

It's a market with an artificial, centrally planned cap on supply. So pretty much the opposite of a free market.

You don't need a permission slip to write your own client with whatever rules you want. You do need to convince people to use if you want it adopted. What do you mean that it's centrally planned?

that's simply not how bitcoin works. the blocksize rule is part of the consensus protocol. you can mine a 2MB block, but no one on the network will accept it and you won't get your reward.

The protocol itself has to be upgraded, and majority has to agree before we can mine bigger blocks.

I'm not saying you don't need consensus. I'm saying anyone can write their own client but the burden is on them to drum up support and achieve consensus if it's going to be useful.

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.

> I'm saying anyone can write their own client but the burden is on them to drum up support and achieve consensus if it's going to be useful.

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

I think the consensus protocol is absolutely not under control of 5 maintainers. Convince a few of the miners and exchanges (e.g., f2, ant, bitfury, coinbase, blockchain.info, bitstamp) to actually start running classic and we'll have 2MB blocks on the longest chain in no time. Conversely, suppose those 5 maintainers release a hard fork version of segwit tomorrow without a block size increase--nobody would upgrade.

The consensus protocol is dictated by exactly that, consensus, not this allegedly omnipotent cabal.

no one is saying they're omnipotent, or impossible to replace. however, you have to admit that replacing them/core or convincing all of these people/companies to adopt anything other than what is coming in core v-next is an uphill battle. I'm going to assume you've been watching this whole blocksize debate, the endless roundtables, conferences... and we're still on square 1. Actually, with classic I think we've at least moved one step forward and a lot of full-node adoption is underway.

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.

It's interesting to me that Bitcoin so rapidly ran into the same fundamental problem that exists with every single decentralized system that tries to function for a centralized purpose. Think about how many 'decentralized' protocols you deal with on a day-to-day basis that try to do this. E-mail, DNS, and the Internet itself via peering come to mind.

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.)

Excellent observations across the board.

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.

Great examples and analysis. I think the IPv6 analogy is spot on--the fear of IPv4 exhaustion (block size limit), the disdain for NAT as an ugly hack (Segwit, LN).

IRC and email are federated systems, they have always been that way. The nature of the federation is different, email systems talk to each other, IRC systems don't. The issue with bitcoin is purely that it solves a problem no-one has, we don't need cryptographic gold. Consensus changes happen to DNS and email all the time, because they solve actual problems and have been made flexible enough to handle change.

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 free market

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.

It's just a fact? Citation needed.

Citation = bitcoin source code.

Which source? Bitcoin is a network of computers speaking a common protocol, not one implementation. Yes Bitcoin core is governed by core. If you're not happy with core then go run a different client or go write your own.

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.

you don't seem to understand how bitcoin works. all the nodes on the network must follow the same rules. neither classic nor XT have different consensus rules. They have change proposals, but those can't be activated until the majority of the network agrees to it - basically the miners mining X blocks out of the last 1000. The majority of miners are on core and until that changes, core is the rules.

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.

Do you honestly believe that the only way to make consensus changes is via pull requests to Bitcoin core?

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.

I think that's pretty evident both historically, and currently. name a single consensus change that was added to bitcoin, in it's 7-year history, that was not a PR to core.

Mostly because the majority thinks Core makes generally good changes. If most people agreed that someone else has made a better change, they'd use that instead.

that has nothing to do with the argument. but re your point that simply is not true either. core was simply never challenged before. all protocol developers simply contributed to core. the rift only happened due to the block size debate. all the past conflicts were about what to put in core and not to launch a competing implementation.

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

Everything Bitcoin is in the Bitcoin source code, by definition. So Bitcoin is completely centrally controlled in all aspects, then?

Everyone loves to talk about the free market, but then are shocked when price discovery raises fees with high volume load

Every market has rules and a platform, that constrain what's possible.

So ability to charge transaction fees is an incentive to keep the block size limit at 1MB?

I have to point out that I'm completely new to this issue and the underlying technology, so pardon me for ignorance.

> So ability to charge transaction fees is an incentive to keep the block size limit at 1MB?

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.

> The big spike seems to be over

Yeah because people got frustrated and gave up.

Yes. This is what the whole blocksize controversy is about. Miners want 1MB blocks because it allows them to collect additional fees more quickly. Companies that depend on Bitcoin's hypergrowth as a transaction platform want to bump the blocksize because they want to keep fees minimal so that adoption stays high. These are the two competing interests.

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.

> Miners want 1MB blocks because it allows them to collect additional fees more quickly.

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'd be interested in a source on this.

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.


If your transaction eventually got confirmed, contact the vendor with the transaction hash. The last three times I used bitcoin, I had to do this; I've yet to be refused by a vendor.

This doesn't make any sense. Why would a company intentionally screw over its customers over such a trivial issue? Their window is 15 minutes because of bitcoin's tendency to fluctuate in price. If the network hasn't delivered your transaction, there's literally nothing they can do. Shouldn't you contact the merchant for a refund?

Brian Armstrong also just posted this: https://medium.com/@barmstrong/what-happened-at-the-satoshi-...

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.

It's not a doubling of expenses, it's a halfing of reward. The reward is meant to go to zero eventually, and halves every four years.

A halving of reward per unit of expense is a doubling of expenses per unit reward.

That said, it is neither - it is a halving of extra reward on top of transaction fees.

Also, "reward" is not appropriate. It has been historically referred to as "miner subsidy": it was intended to be a way to make mining attractive for early adopters.

Correct me if I'm wrong, but doesn't this just mean that fees have to be higher? Welcome to markets, where technical constraints and supply/demand dynamics both influence price.

I believe the issue is overall capacity. Sure, you can up transaction fees and get your transaction processed rapidly. But that's not a sustainable strategy if bitcoin continues to rise in popularity. Since total capacity isn't increased, you will have more and more people competing for what capacity exists and this will lead to ever-escalating fees.

Yea this is really not a big problem. Currently people are using Bitcoin to move around amounts as small as a tiny fraction of a cent. That's just a waste of blockchain space. We all know there needs to be a transaction fee to stop these so-called 'dust transactions'

It's a market with an artificial, centrally planned cap on supply. So yes, it means that fees have to be higher, but it also means that some people/transactions will necessarily be priced out (or move to alternative, cheaper blockchains, as is currently happening).

Exactly. The issue is that people are to accustomed to paying little to no fees, so nobody wants to pay a few cents more for faster confirmations.

Having little or no fees was supposed to be one of the big advantages of bitcoin compared to traditional financial transactions.

Not true at all. I'm not sure where people get this idea but if you read Satoshi's original paper you'll see that this is just false.

Unfortunately, this is how Bitcoin was promoted for a long time. "Free, instant transactions!" It always bugged me.

My transaction just cost nearly $1, so yeh, thats a lot of cents for some people, and the point is that it is an unnecessary constraint.

The tone of the article is objective, but surely Coindesk has an interest in Bitcoin Classic. I read it as nothing more than propaganda.

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.

They have an interest in bitcoin working, I'm not sure what other ulterior motives you think they have to the actual protocol.


You think coinbase wants to control the protocol? How would they do that exactly? The best way we've seen so far is to stuff the developer list with people you've bought off and alienate the others, which is what blockstream is doing and what is happening right now.

Coinbase has an interest to increase the block size so that the protocol can be further centralized, making people more reliant on their centralized bitcoin as a service business.

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.

I'm really not sure where people are getting this. All companies with the exception of Blockstream want Bitcoin to scale so that it can aquire more users. More users is instrumental to the growth of new companies. Not scaling the network means we will cease to aquire active users, and the entire ecosystem will possibly stall. While that happens we will have capital outflow to other coins.

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.

Why is it a sinking ship? I can still send money to anyone anywhere in the world for a very low fee relatively fast, without any restrictions, long forms or questions asked. I don't know what do you think Bitcoin's value is to people, but I surely know what value it has for me personally.

Sinking doesn't imply fully sunk. Yes, bitcoin is still semi-useable but it's becoming less and less so. Meanwhile businesses are chomping at the bit to bring it fully under their control so they can profit more from it. There are much better alternatives.

Semi-usable? How so? I regularly buy things with Bitcoin and I haven't noticed any decline in products and services being offered for Bitcoin. Expedia still accepts it. Cheapair still accepts it. Dell still accepts it. Many other large and small businesses accept it. Yes, it's not the same level of penetration as credit cards, but CC have been around since when? And Bitcoin? Have a sense of proportion.

1) What are the "much better alternatives"? 2) I've made 4 transactions in bitcoin this week, none of which had any problem being confirmed. 3) If people switch to alternatives, don't you think people will be incentivized to decentralize them for their own benefit just like bitcoin?

How financially invested are you in Ethereum?

Not at all. I hold about $5 worth of bitcoin, but that's it.

It seems to me that you have it completely backwards.

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.

You're thinking of coinbase. Coindesk is s blog

Oops, thanks.

I suspect you have a horse in this race, but it is certainly true that a lot of investors -- both in the currency and in the companies -- are now in too deep, and they know it. That goes for all your alternatives as well.

> Coinbase has an interest to increase the block size so that the protocol can be further centralized, making people more reliant on their centralized bitcoin as a service business.

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.

It's also verification and storage, including RAM for the mempool.

So, I looked up Ethereum hoping to find a dencentralized digital cryptocurrency with transaction times comparable to credit/debit card transactions, but instead I found..I found..what did I find? WTH is Ethereum?

zcash looks promising.

I can't help but notice that the only news about Bitcoin that ever enter HN front page are some sort of drama, or "issue with bitcoin". There are a lot of truly great things going on in the space, yet these are carefully kept off the mainstream news outlets and even HN.

Does Ethereum have the same scaling issue if a group setup a direct currency on it?

Is there anything preventing an implementation vote by the miners? I would think that convincing 50% of miners would be all it takes to change these types of features.

Up to a point, miners have an incentive to increase transaction delays in order to drive up fees (which they receive).

Miners can't increase transaction delays in practicality because they need their blocks to propagate to be able to capture the mining fees.

> Miners can't increase transaction delays in practicality because they need their blocks to propagate to be able to capture the mining fees.

They get the mining fees regardless of whether they include your transaction or any others for that matter.

The miners get the Block Reward without including transactions but they earn extra Transaction Fees for each fee-bearing transaction they include in the block too.

IIRC, The majority of the blocks are "mined" in China where they continue using the "old" fork of Bitcoin instead of the "new" fork that upped the block size. I would assume they're resistant to change as keeping the block size down can, over time, force the transaction fees up (bringing in more cash for the miners)

China has people in both camps.

I find it funny how all talk about decentralization, but ignore the fact that most mining is in China, a known bastion of freedom.

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)

All kinds of silly things are illegal in China, even copyright infringement, but that doesn't mean the police are breaking down people's doors and confiscating their computers. People flagrantly do many of the illegal things anyway.

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.

That is what Classic is, except they are using 75% as their consensus threshold (it is arbitrary though - if you maintain 51% of hash power you can dictate the protocol).

It's not really 51%. The miners are supposed to accept the "tallest" chain. So you can get lucky and mine a block then change the rules and sneak in some breaking change (like a larger block). No one else will accept it unless you can keep mining quicker than everyone else and eventually convince everybody that yours is the "true" blockchain so everyone else should switch. The thing is if you have less than 50% of hash power, it's extremely unlikely you'll be successful because 50%+ other miners disagree. Once you get above 50%, you're chances go up but you're still playing with fire here because just a short period of bad luck can end up breaking your "fork". Even at 75% there would be some big issues with the 25% left behind who might not initially realize what's happening (and maybe get lucky).

>The miners are supposed to accept the "tallest" chain.

The tallest valid chain. A chain with block sizes exceeding the max won't be considered valid.

If you do something like a larger block it doesn't matter if you have the longest chain because no one will be relaying it.

The fork accepting more kinds of block is probably going to be jittery and broken right at the switchover no matter what. The percentage only affects how fast things stabilize. 60% would be fine after a couple hours. Requiring 75% or more is to smooth things on a political level.

Because it's a consensus rule (enforced by every fully validating node), it would require a backwards incompatible change (hard fork) to be implemented by every single miner, exchange, wallet and merchant. Only soft forks (which are backwards compatible) can be rolled out with a 51% miner vote.

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.

"up to" being the key word in the title. Don't pay enough fees and it'll take even days.

I think this vindicates the banks' decision to build their own blockchains instead of building on top of the Bitcoin blockchain.

Which is part of the reason why I think taking the long side in the brewing short squeeze in XMR will be brilliant for me.

If companies like Coinbase, which live and die by the health of the Bitcoin ecosystem, have taken so much capital, why can they not solve this problem by spending money to shore up the health of bitcoin ecosystem (I assume this requires adding processing power)?

I don't know anything about Bitcoin, so maybe it's just unfeasible.

This is the paradox. Coinbase does not gain anything if bitcoin gets better. Their business is "we make bitcoin use easier". If both users are Coinbase customers, their transaction is done outside of blockchain. Their goal is to have more users and wonky or slow transactions outside of their servers helps them.

They are. Coinbase has several bitcoin devs on their payroll, and they have thrown their support behind a scaling plan that includes bigger blocks.

If they do, these parties are not disclosing it AFAIK.

Wow why am I being downvoted?

Why it takes so long? Because network is being DoSed. How? By sending a lot of small transaction to fill out blocks - they also pay for those transactions. Why? Well, to prove the point. "You need bigger block, you need our fork".

DDoS - the best weapon of Internet, still undefeated.

They're paying, so who gets to declare them a "ddos". Also if <2 transactions per second is "ddos" then the protocol is flawed.

Lol wut? It's the classic nodes being DOSed. Also, the whole network being full isn't even supposed to be a problem, according to Core. Prices will just rise? Correct?

This has been going on, on and off, since before Classic and XT and all the others were announced. Someone's been spending a fairly substantial amount in transaction fees to send spam transactions in order to "prove" that the block size needs to be increased and openly bragging about it.

Doesn't the action actually prove the point? At the very least, it's proof that the network is vulnerable to this kind of attack. Seeing as it has been ongoing, it can't be that expensive to do, since it isn't really going to result in a financial payoff for the attacker.

You don't have to be smart to understand the universe is resource bound. Bitcoin core seems to have made a money that has a "resource" like behaviour.

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?

> 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)

Welcome to the real world, where companies are ran for profit, not for some "greater good". I can safely assume you have never owned a company. How would you feel if you would not get paid for your work, but it would instead be handed out to homeless people for the greater good (as an example)?

You unsafely assumed. I had more than one business.

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).

> "How would you feel if you would not get paid for your work, but it would instead be handed out to homeless people for the greater good (as an example)"

Why can't I have both? For example, the taxes the company pays could cover looking after homeless people.

Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact