Comment by lambda | Hacker News Reader

Comment by lambda | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com