Comment by buttershakes | Hacker News Reader

Comment by buttershakes | Hacker News Reader

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

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

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.

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

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

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.

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

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

https://www.decred.org/

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.

Reply on news.ycombinator.com