How faster transactions can be implemented

[ziliboba487]

The "difficulty" manages to have one block built not faster than in 10 minutes in average. It helps to avoid collisions. If we decrease the difficulty to have 1 block in 10 seconds instead of current 10 minutes, we would have way more collisions, and the blocks we mine will have higher chance to be discarded.

What can be a solution for a decentralized pool of nodes around the world? May be already invented but I am not aware?

[BlackHatCoiner]

What do you mean a decentralized pool of nodes?

A pool where everyone has the same rights? Where there's no owner? There isn't such thing, but even if you didn't know it, what would be the obvious answer? Why would the miners work on “centralized” pools while there were “decentralized”.

The sooner you understand the purpose of working for a pool, the sooner you'll comprehend the need for this kind of pools we already have. Essentially, the decentralized pool is the network and these pools derive computational power from miners to compete who's going to solve the next block. Then, they reward miners accordingly.

[n0nce]

It's unclear what you actually try to ask; so I will just answer the title of your topic, which is probably your main question - accelerating transactions.
The best way to do so is not to shorten the block time, because scaling in general can't be feasibly done on a large-scale level purely on L1. It's best to keep L1 simple, and easy to run, and use that to secure sidechains and off-chain mechanisms such as Lightning Network.

Finally, I don't get how people always complain about Bitcoin's speed. When I send bank transfers, it often takes hours or until the next day for the money to arrive at the receiver, even though we're in the same country. International takes even longer. Meanwhile, easy pure good old Bitcoin L1 settles your transaction permanently in on average 10 minutes - that should be quick enough for most things.

Again, for micro transactions, 'streaming money' and the like, feel free to try LN, it works pretty well nowadays. And no blockchain can be this fast, even 10s block time would be pathetic compared to off-chain solutions that are virtually as fast as your network allows to send data.

[DannyHamilton]

The "difficulty" manages to have one block built not faster than in 10 minutes

Many blocks are faster than 10 minutes. As a matter of fact, more than half of the blocks solved are solved in less than 10 minutes.

in average.

Correct, the difficulty is adjusted every 2,016 blocks to bring the AVERAGE time between blocks as close to 10 minutes as possible. This is the speed of blocks, not the speed of transactions.  Transactions have many different speeds, depending on what you are trying to accomplish. There is the time to create a transaction, the time to broadcast a transaction, the time for a transaction to be relayed throughout the majority of nodes, the time for the first confirmation, the time until the recipient is willing to release whatever is being exchanged, and the time until most people feel confident that the block containing the transaction won't be replaced.

What can be a solution for a decentralized pool of nodes around the world?

Nodes are already decentralized. That has no effect on the time for blocks to be solved and has minimal effect on the time for transactions to be relayed. Since nodes are already decentralized without a pool, why do you want a pool?  Who would participate in the pool, and why? What benefit would come from a pool of nodes in place of individual nodes?

Perhaps you mean pool of miners instead of pool of nodes?  Those already exist. This allows those supplying hashpower to work together on solving a block, and then share the rewards from the block. That way their is less volatility in frequency and value of earnings from hashing. This has no effect on the frequency of blocks nor the speed of transactions globally.

May be already invented but I am not aware?

Maybe.  Depeends on what you are trying to accomplish, and why you think a pool is the appropriate solution.

[o_e_l_e_o]

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.

Finally, I don't get how people always complain about Bitcoin's speed. When I send bank transfers, it often takes hours or until the next day for the money to arrive at the receiver, even though we're in the same country. International takes even longer. Meanwhile, easy pure good old Bitcoin L1 settles your transaction permanently in on average 10 minutes - that should be quick enough for most things.

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.

[larry_vw_1955]

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.

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.

[Quickseller]

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.

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.

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.   

[d5000]

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

[o_e_l_e_o]

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.

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.

[odolvlobo]

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.

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.

[d5000]

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.

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

orphan rate ~= t/T

where T is the mean block time and t is the average block propagation time to the network's hash power.

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.

[larry_vw_1955]

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.

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?

[Quickseller]

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. 

[pooya87]

Some people in the thread however complain about LTC orphan rates of around 10%, but they may have bad network connections.

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.

[d5000]

Some people in the thread however complain about LTC orphan rates of around 10%, but they may have bad network connections.

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.

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

[pooya87]

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

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.

[n0nce]

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

[odolvlobo]

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

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.

[d5000]

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

Shorter block time:

    PRO - Faster 1 confirmation time (to protect from 0-confirm double spend)
    PRO - Less payout variance for miners (less reliance on large pools)
    CON - Requires increased bandwidth (inter node communication)
    CON - More forks, longer forks, and longer re-org time
    CON - A greater portion of the raw hashpower is wasted, resulting in lower effective security.

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.

[Quickseller]

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

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.

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.