Topic: How faster transactions can be implemented - page 2. (Read 663 times)

The conclusion is that the Lightning Network is much better for retailers and customers, because not only they get their transaction confirmed instantly, but they also, both, retain their privacy and pay less in fees.

How's that true? Is it a mathematical parity in probability theory that I'm not aware? I would really be interested to know more.

I don't understand this. Do you want to belie the Lightning Network? Which part of it is more complex and by who?

As has been mentioned by multiple people (including myself), LN is superior for retail transactions.

However when determining if the amount of time is acceptable for a retail establishment in terms of payment confirmation, it is more complex than the worse case scenario for when the next block will be found.

It is important to note that the average block time is going to be twice the average amount of time until the next block at any given time. So on average, over many transactions at an establishment, if the average block interval is 1 minute, the average amount of time until the next block is found will be 30 seconds -- about half the time it will be less than 30 seconds, and about 1/2 the time it will be longer.

From an operational standpoint, it is important to understand where the bottlenecks are, and how long they are. At a coffee shop for example, there are bottlencks at the line to place an order, and at the barista who is making various orders. In my experience, there is a longer bottleneck at the barista than there is to place an order. This means if there is a 1 minute block interval, the coffee shop could direct the customer to proceed to the waiting area after 5 seconds when the coffee shop is confident the transaction will confirm in the next two blocks. While the coffee shop is waiting for a confirmation, the order can be placed in the queue (as is the case today with cash/credit card txns), and once the order reaches the front of the queue, if the txn has not yet confirmed, it can be moved back one place in favor of another order (or the coffee shop can elect to accept the unconfirmed txn provided certain criteria is met, such as no blocks being found, and no recent double spends against them).

There is a similar bottleneck at fast food restaurants, and a similar procedure can be implemented. At dine-in restaurants where payment is typically made after the meal is consumed, waiting 5 or 10 minutes for a confirmation should not be a major concern.

A retail establishment is more complex. There is currently a single bottleneck and that is waiting in line for the clerk to "ring up" the items a customer is buying. In addition to "ringing up" items, clerks will also place purchased items in bags. One solution might be for the customer to "scan" the items being purchased prior to interacting with the clerk, paying for the items via a txn, and by the time the clerk has finished placing all items in bags (which will not happen until the clerk has placed all previous customers' items in bags), hopefully the txn will have confirmed.

Also worth noting that Monero initially had a block time of 1 minute, but increased it to 2 minutes in 2016, partly due to an excessive number of stale blocks.

This is essentially the point I was making above. The probability of not mining a block within the next x seconds, when the expected block time is y seconds, is given by the following equation:

e^(-x/y)

If you drop the block time to 1 minute, then the probability of not mining a block within a minute is

e^(-60/60) = 36.8%

13.5% of blocks will still take longer than 2 minutes, and 1% of blocks will still take longer than almost 5 minutes. And this is all assuming that your transaction makes it in to the very next block, and the merchant is happy with only one confirmation despite the increased risk of stale blocks.

None of this is acceptable for a point of sale transaction. You are either going to have to wait for confirmations anyway, which you would be doing already if you were buying online or making a large purchase such as a car in person, or you are going to have to accept zero confirmation transactions or use Lightning. No one is going to hang around waiting for a confirmation while their coffee gets cold, regardless of if the block time is 10 minutes or 1 minute.

If you want to argue for a shorter block time for other reasons, by all means, and I do think there are some good arguments for doing so, but it will never solve point of sale transactions.

Yeah; correct - there is no way to get like '1 tenth security' of a single confirmation in Bitcoin, that's right. But I don't understand the application / scenario.

Waiting for 1 minute (on average! It can be significantly longer - we sometimes see 20 - 30 minute block intervals in Bitcoin..), is not feasible at the counter of a brick-and-mortar store; it's way too long. And for online purchases, waiting 1 or 10 minutes makes no difference in terms of when the item arrives. It's not like the processing takes days.. So I see no added benefit but many potential and real issues.

If a transaction is not opting in to RBF, I would argue that a zero confirmation transaction has modest amounts of security. Obviously a single confirmation has much more security than zero confirmations. Once a transaction has a single confirmation (with a 10 minute block time), the chance of loss goes down to close to zero, and will incrementally decline until 6 confirmations, when the risk is still something very close to zero, but not zero, and will not decline further as the transaction receives additional confirmations.

Someone accepting (and exchanging value for) an unlimited amount of bitcoin will want to wait for 6 confirmations, especially if they receive large amounts of bitcoin. However this is not true for retail establishments, as they are limited by their available inventory, are further limited by bottlenecks at the checkout process, and are further limited by the fact that many retail establishments will require some kind of a delay when selling very large amount of inventory to a single customer.

While it is not especially uncommon to see an orphan bitcoin block (d500 cites data suggesting about 0.5% of blocks are orphaned, which works out to about 2 every 3 days), it is uncommon for a transaction confirmed in an orphaned block to not get confirmed shortly thereafter. This implies the risk of accepting a 1 confirmation transaction is very low. Double spending a transaction that received one confirmation generally requires both mining hardware and multiple tries at double spending (or without mining hardware, MANY tries, even with RBF enabled).

I speculate at least part of the reason for the above is that most miners (the entities that actually propagate found blocks -- eg pools and solo miners) are well connected to the network, and follow similar rules to maximize tx fee revenue. Having a 1 minute average block time would obviously allow for more entitles to enter the mining world, and the rate at which a particular mining entity has not yet received a particular transaction as of when a block is found would probably increase.

I am curious if anyone has run any simulations on the effect shortening the average block time has on the percentage of transactions getting double spent that were included in an orphaned block. It shouldn't be especially difficult to figure out a way to compensate miners for orphaned blocks (such as eth's 'uncle' system). The more important issue is the risk of loss in accepting n confirmations when the average block time is changed.

I agree both with n0nce and odolvlobo. The security of a 10-minute confirmation is equivalent to 10 1-minute confs, but in Bitcoin you don't have anything close to a 1-minute-conf (zero-conf or nothing).

The 10-minute interval, according to a stockexchange post, was chosen because Satoshi believed that block propagation would be slower (1 minute), but things have improved greatly since then. The Bitcoin whitepaper also cites indirectly the advantage of a low requirement for space for block headers if the nodes do pruning (~4,2 MB/year, in the case of LTC you have already ~17 MB for headers alone, an 1-minute Bitcoin would have 42, and in the case of a "15-second-Bitcoin" about 160. These numbers look small when we look at current HD and RAM capacity, but it still is an advantage of the "slow" Bitcoin.

The most voted Stackexchange answer cite also other aspects of this "tradeoff":


The point with the "wasted" hashrate is maybe somewhat debatable. The security of a cryptocurrency depends on the money being wasted by an attacker to get 50%+ of the hashrate, not on its "raw" hashrate. Thus, an attacker also has to take into account the stale block/fork rate while he tries to make his attack chain the canonical chain. However, as attack forks are typically short, and he can mine a large part in secret (without having to fear stale blocks) they're may be less relevant to them.

PS: I think Bitcoin made a pretty good tradeoff with its 10-min blocks, although if sidechain mechanisms like Drivechain became reality, I would bet on them choosing an interval more close to 1 minute, as some of the tradeoffs aren't that important for them.

@pooya87: Yes, they seemed to be solo miners. 2016 was still in crypto winter, and I mean to remember that altcoins were even deeper immersed in it (had 90%+ losses compared to their previous ATH), so solo mining should have been normal then.

That's true, but the key is that there is a huge difference between no confirmation (no security) and 1 confirmation (some security), especially with RBF, and even with a shorter block time.

I would disagree with this. If you reduce block time, you need to proportionally increase the number of confirmations for the same level of security. For example, 1 confirmation now would be 10 confirmations @ 1 minute block time. Since the same resources to reverse 1 block now could reverse ten 1 minute blocks. Makes sense? So the same 'amount' of transaction finality & security will always take the same amount of time, no matter how fast your blocks come in. If you have a difficulty target & block time so high that a block only gets mined once per hour, 1 conf would be equally as secure as 6 confirmations in today's Bitcoin. Just to show the other extreme..

If you assume that customers at a brick-and-mortar store, spend amounts way too small to make an attack feasible, you can either accept 0 confirmation transactions. As far as I know, that's how BTC-accepting stores did it so far. Or just use the Lightning Network or a future, maybe better, L2 alternative.

That makes more sense but only if these litecoin miners were actually solo miners running their own node instead of connecting to a mining pool (similar to bitcoin miners). I don't really follow LTC scene to know how things were back in 2016 but since LTC follows bitcoin in most things, pools might have been what everyone connected to, in which case the rate depends on the pool's connection quality not the miners.

My post was probably not clear enough. These people complaining about a high orphan (=stale block) rate were miners talking about their own stale block rate (=number of blocks they found, but were discarded by the "longest chain", versus the total number of blocks they found).

I for myself can only imagine that their connections weren't ideal. Maybe they also had simply bad luck and their "sample" was too small (if they were low-hashrate miners and do not find that many blocks at all). Maybe also the 6 seconds the reddit user mentioned was too optimistic in the LTC network (where afaik there are still many smaller miners and I don't know if they use Fibre or a similar protocol).

Orphan rate (or I believe you mean stale block rate) is a universal thing that depends on miners not something that individual nodes would experience based on their connectivity. If a shorter chain is created then all nodes would technically find out about it, a node with bad connection finds it later.

A business receiving cash cannot effectively spend it instantly because most of their bills are those that require payments being sent to locations far away. Also, payment due dates are not immediate, so this is generally an issue. Most businesses will have some kind of armored car service pick up cash deposits, which often will not happen daily and takes time for the bank to process.

The underlying issue is not when a business actually receives a payment, the issue is when a business knows with x amount of certainty that they will receive a payment. With bitcoin, this can be as quickly as a few seconds, even with a 10 minute block time, as long as certain criteria is met with the transaction (RBF being set to False, no unconfirmed inputs, sufficiently high tx fee, etc). It is difficult for a business to ensue a transaction has a high probability of quick confirmation because the sender has so much control over the transaction.

The above would again make me want to circle back (please don’t discredit me for using this term), to L2 solutions. LN will ensure that a business will receive a payment nearly immediately, and if the transaction fails, both the buyer and seller will know immediately. 

Well, i get what you're saying but certainly there's other cryptocurrencies that have faster confirmation times than bitcoin and they are just as final as bitcoin. But in general I think I agree. physical cash would include things like western union right?

I've found this formula at reddit (in a thread where folks compare LTC, BTC and Doge stale block (orphan) rates):


According to that formula, if the block propagation time is 6 seconds (like the Reddit user assumes), BTC has a "theoretic" orphan rate of 1%, LTC, with a 2.5 minute block interval (thus 4 times shorter than BTC), of 4% (the thread wrongly states 2,5%, but LTC has 150 seconds, so it's 6/150 which is 0.04).

Some people in the thread however complain about LTC orphan rates of around 10%, but they may have bad network connections. And I've seen "real"-data based estimations for BTC of 0,5%. Blockchain.com used to have a stale block chart but it only covers years between 2014 and 2017. It seemed to show rates of 0,1 to 2 blocks per day, with a decreasing trend since 2015.

The difference between the "lower-than-expected" Bitcoin stale block rates and the "higher-than-expected" LTC rates may have to do with the greater professionalism in BTC mining (also take into account the Reddit thread is from 2016 or so), which led to the specific network protocol which connects mining pools. I now remembered its name, it's called Fibre Network.

Now the question is: what is the "optimal" stale block rate? Is an increase from 1% to 4% still acceptable? An 1-minute-blockchain would have 10%. Ethereum, like I wrote above, with its 15 sec block interval has 40% of theoretic orphan rate and thus already needs a compensation mechanism (uncles) to avoid an excessive mining centralization, but one must say that a part of their hashpower is basically wasted.

Here is another thread about stale blocks, with input from gmaxwell.

I agree that even a 1 minute block time is not short enough in your particular scenario, but certainly a shorter block time is better in general, even if it isn't a "solution".

I don't know what the optimal block time is when considering downside of stale blocks, but I bet it is much less than ten minutes. And with improved communications in the future, the optimal time could become very short -- less than a minute. Maybe we could shorten the block time now to 1 minute in order to prepare for the future.

They might debit your account immediately, but the merchant does not receive the money immediately and still has to wait a few business days. And as has been said above, these transactions are still reversible for weeks or even months after they are made. The same is true for things like PayPal, Google Pay, Apple Pay, and so on.

The only fiat method which is faster and more final than bitcoin is physical cash.

I fully agree with what among others o_e_l_e_o, DannyHamilton and nonce0 have written. Layer 2 is the way to go for shorter transaction confirmation times.

But @OP, I suspect* that your reasoning goes the following way, which would explain the slightly confusing OP:

"Collisions" between competing blocks, as you call it, could be decreased if all miners were connected better between them - i.e. in some kind of decentralized pool which ends finding all the blocks.

There was a protocol called P2Pool (I think it's this link, but be careful), which was decentrally organized as a P2P network, and - if I remembered well - used an own blockchain or ledger to distribute the rewards to the nodes. I don't know why but at least in recent years it never had big mining shares.

Maybe centralized pools are faster (the website lists also higher CPU/RAM requirements as disadvantages). But having a centralized pool finding all the blocks (or more than 40-50%) would not be desirable, because the pool operator could attack the network then. It is possible that if in the case that if P2Pool was the dominant mining pool attacks were also possible, I don't know the protocol in detail.

You could get similar effects with a faster network which connects only miners, where they can listen to other pools submitting their blocks, so they don't submit a block slightly afterwards which would be orphaned. Such a network does, or at least did, exist between some pools; but I don't remember its name.

There is also Ethereum's "uncles" concept, where some orphans get rewards, but this only solves the problem for miners, the efficiency of the network is (as far as I understand) not affected and lower as in "slower" chains like BTC.

*in the case this is a serious technical question - briefly looked in the user's contributions and they don't give me too much hope

The issuing bank (via the debit card network) can reverse a debit card transaction under certain circumstances. The money being immediately debited from your available balance allows the bank to know the transaction will not be declined due to insufficient funds.

The biggest difference between using a credit (or debit) card and accepting a zero confirmation bitcoin transaction is that the merchant will largely know the identity of the person using a credit card (unless the physical card is stolen), while a bitcoin transaction is, for all intents and purposes anonymous in many cases.

Most merchants do not need the money in their bank account immidiately, they only need a commitment from someone that is reliable (such as a card network) that payment will be received in due time.

I think the most likely long term solution to in-person payments being completed quickly on any kind of scale will be Lightning, or some other similar L2 protocol.   

Credit cards take time to settle but debit cards are instant. they take the money out of the account immediately or they decline it immediately.

Shortening the block time will never be a solution for faster transactions.

The most common scenario to need a fast confirmation is a physical point of sale transaction - where I am in a store in person, paying for goods at a cashier. These sales need to take place within seconds. Even a minute is too long to wait for a busy cashier with a queue of people waiting to pay. To achieve this you would need to drop the block time to well under a minute, which would cause so many stale blocks (as you point out), that you would end up having to wait for more than a minute anyway to be sure the chain of blocks you are viewing isn't about to be discarded for a longer chain.

The solutions to this are for merchants to accept small value zero confirmation transactions, or to use a second layer solution such as Lightning.

Because people don't understand the fiat system, and so compare a transaction being broadcast with fiat to a transaction confirming with bitcoin.

When I swipe my credit card in a store, that is pretty much the same as broadcasting a still unconfirmed bitcoin transaction. I see the transaction on my wallet or app, the merchant can see the incoming transaction, but no money has actually moved. For some reason, people think that the credit card transaction is now complete, and the bitcoin one isn't, whereas in reality the fiat does not actually reach the merchant for 3-5 working days and can be reversed for anywhere between 90-180 days, while the bitcoin reaches the merchant and cannot be reversed after ~10 minutes. They compare broadcasting a credit card transaction to a bitcoin transaction becoming irreversible, which is obviously an unfair comparison, then lambast bitcoin for being so slow, while in reality the bitcoin transaction is orders of magnitude faster to finalize than the credit card transaction is.