please delete

[SapphireSpire]

nothing to see here

[1715308490]

1715308490

[1715308490]

1715308490

[NeuroticFish]

Reducing block time is bad for security. Just look at exchanges: the faster the block times, the more the confirmations they want for deposits.
Bitcoin ~10 minute blocks were pretty well thought and I would not expect that to change in the near future.

If one wants fast transactions, he should look at LN, not try to change a perfectly working bitcoin.

[BlackHatCoiner]

With the network hash rate so extraordinarily high, why is the transaction capacity so low?

Because they're apples and oranges. Transaction capacity doesn't have to do with network's security.

The best blockchain is the longest chain with the greatest POW

This is pleonasm. Just the one with the most work.

To increase transaction capacity, the block interval can be reduced by reducing the block hash difficulty.

There are various ways to increase the transaction capacity. One is to just increase the block size. Another way is to mess with block intervals, as you say, which involves trading off security. The fact remains: You don't scale. Scaling isn't a matter of transactions per second. It's a matter of transactions per second per block size. If you just adjusted the block size limit to 1 TB, and left transactions as is, you shouldn't call that "scaling". Scaling is when the size of transactions becomes less than it was before.

Bitcoin can already process more than VISA can do, with second layer solutions.

[Charles-Tim]

All these suggestions are no more new. Faster transactions would only result to more possibilities of chain reorg and reduce the bitcoin blockchain security.

In short, Bitcoin can be faster than VISA if it needs to be.

If you want faster transaction, you can use lighting network. There are wallets like Bluewallet that makes it easy to use nowadays if you are not that good with bitcoin technical aspect.

[stompix]

With the network hash rate so extraordinarily high, why is the transaction capacity so low?  Wouldn't it be great if we could focus all that hash power on faster transaction processing instead of a high block hash difficulty?  Well, we can!

Hashrate has nothing to do with the capacity of the network.
Just for fun, the Hahsrate now is 260Exahash, in early 2013 it was in 100 Th/s range, it doesn't mean that the capacity or speed of transactions has grown 2 million times, the only thing you can take out of that is that you need 2 million times more computing power to launch a 51% attack on the network.
The block time is the same, so although there is an increase in capacity due to segwit it's nothing that radical and it has nothing to do with the difficulty and the hashrate.
 

In short, Bitcoin can be faster than VISA if it needs to be.

No, it can't.
As mentioned above by BlackHatCoiner there are two different things capacity and speed.
Of course, constantly increased capacity will lead to every transaction in the mempool getting confirmed in the next block but it will still not make them instant, if the next block is mined in 20 minutes from when you broadcasted it will still take 20 minutes for a confirmation.
So no, on-chain transactions will never match Visa speeds, there are two different things and two different systems that serve different purposes, if you want competition with Visa speeds you have to look at LN.

[o_e_l_e_o]

In short, Bitcoin can be faster than VISA if it needs to be.

Why do you think Visa is currently faster than bitcoin?

If I have just eaten a meal in a restaurant, I could pay with either credit card or bitcoin. Whichever one I choose, I broadcast my payment to the network and the restaurant sees my payment show up in their account/wallet immediately. With bitcoin, the restaurant owner can spend the money immediately if they want, and the transaction becomes irreversible in 10-20 minutes, probably before I've even left the restaurant. With a credit card, the restaurant owner cannot spend the money until it actually arrives in their account 3-5 business days later, and the transaction remains reversible for up to 180 days.

The same fundamental premise holds true of any and all electronic fiat methods, be they credit cards, bank transfers, PayPal, Google/Apple Pay, etc. All of these can be reversed for a significantly longer period of time than bitcoin transactions can be reversed.

[PrimeNumber7]

(as others have noted) It appears the OP is conflating transaction throughput with transaction speed. Throughput is the number of transactions that can be handled per n period of time, while transaction speed is the time it takes for a transaction to settle/finalize.

The reason why bitcoin's transaction throughput capacity will be lower than Visa's is due to the fact that bitcoin transactions must be transmitted to everyone running a full node on the network (and each transaction is similarly stored by everyone running a full node), while Visa transactions only need to be transmitted to a Visa computer.

I might compare someone "swiping" their credit card at a merchant, and the payment processor (using the Visa network) telling the merchant the transaction was "authorized" to an unconfirmed bitcoin transaction. In most cases, the transaction will be finalized and will not be reversed, but there is still the potential for a reversal (or in the case of bitcoin transactions, a double spend).

[o_e_l_e_o]

I might compare someone "swiping" their credit card at a merchant, and the payment processor (using the Visa network) telling the merchant the transaction was "authorized" to an unconfirmed bitcoin transaction. In most cases, the transaction will be finalized and will not be reversed, but there is still the potential for a reversal (or in the case of bitcoin transactions, a double spend).

Exactly my point. Neither an unconfirmed bitcoin transaction nor a Visa authorization of payment are final. However, the bitcoin transaction is difficulty and costly to even attempt to double spend (certainly not worth it for the price of a meal in a restaurant) and the double spend attempt has a high chance of failing, while a Visa transaction can be reliably reversed easily and for free with a single phone call claiming that your card was stolen. Further, the window for a bitcoin double spend is ~10 minutes, while the window for a Visa reversal is 180 days.

The only form of money which is instantly confirmed and irreversible is cold hard cash, with bitcoin being a close second. Everything else is a very distant third place.

Having said all that, this situation will change somewhat when full RBF is released with Core v24.0. At that point, zero confirmation transactions will be easily reversed, so you either have to trust your customer not to scam you (as you do with every credit card transaction), wait for a confirmation (still much quicker than 180 days!) or use Lightning.

[DannyHamilton]

The only form of money which is instantly confirmed and irreversible is cold hard cash, with bitcoin being a close second.

And with cash there is a higher risk of unknowingly accepting counterfit currency. It is also much more difficult (and slower) to make a "cash" payment to someone that is not in the same physical vainity as you.

[o_e_l_e_o]

And also the hassle of carrying cash, accepting cash, keeping appropriate amounts of change and coins, the higher risk of theft, the inconvenience, cost, and risk of having to take that cash to a bank to deposit it, and not to mention that many merchants don't accept cash above a certain limit or even don't accept cash at all.

When you consider all the disadvantages of the various types of fiat payment methods, bitcoin is clearly the superior currency as far as I am concerned.

[NotATether]

Bitcoin can already process more than VISA can do, with second layer solutions.

I know everyone would like to think that including myself, but that is simply not true. Otherwise, more people would be using the Lightning Network and possibly Liquid than Layer 1 mainnet by now.

The truth is, that LN and other existing solutions increase throughput somewhat, but that increase is not scaleable any further.

[BlackHatCoiner]

I know everyone would like to think that including myself, but that is simply not true.

Why isn't it true? The Lightning Network works as a network of mini-VISA nodes. It is natural to can handle more transactions than VISA.

Otherwise, more people would be using the Lightning Network and possibly Liquid than Layer 1 mainnet by now.

There are a million other reasons why people don't use bitcoin currently as currency. Yet, that's not one of them.

The truth is, that LN and other existing solutions increase throughput somewhat, but that increase is not scaleable any further.

That somewhat is sufficient enough for a global scale.

[Pmalek]

Having said all that, this situation will change somewhat when full RBF is released with Core v24.0. At that point, zero confirmation transactions will be easily reversed, so you either have to trust your customer not to scam you (as you do with every credit card transaction), wait for a confirmation (still much quicker than 180 days!) or use Lightning.

How easily? Are we talking about a click of button in a piece of software?

Is this full RBF feature going to be an optional feature, or is that the new norm for RBF-enabled transactions? What I am asking is, can I use the "standard" RBF we have now or go with full RBF, or will their be no "standard" anymore? What is the reasoning behind implementing this? Giving the sender a chance to change their mind if they were too hasty and made a mistake or what? On first sight, it seems more harmful than an improvement but I would need the whole picture to be able to judge it properly.

It could also require services that accept unconfirmed transactions to completely re-think their business model. Crypto casinos, for example. Although, they already have in-built protection where the deposit transaction has to be confirmed before the player is allowed to withdraw their winnings from the platform. Trying to cheat already means shooting yourself in the foot. What about instant swaps between lightning and on-chain BTC? Submarine swaps don't require on-chain confirmations I think. Seems all that will be negatively affected if full RBF can't be deactivated manually.

[dkbit98]

In short, Bitcoin can be faster than VISA if it needs to be.

Same thing was said by every shitcoin fork developer in the world, and look what happened with all of them, especially BSV crap with totally unsustainable centralized blockchain
There is no need to create super fast maninnet for bitcoin blockchain, when you already have second layer solutions and Lightning Network that are already faster than Visa.
You would start changing this first and than you would end up with centralized PoS mostly censored blockchain like in case with ethereum, and someone just needs to flush the water in toilet.

[o_e_l_e_o]

How easily? Are we talking about a click of button in a piece of software?

Every transaction will be treated as opted in to RBF, so double spending any unconfirmed transaction will be as easy as double spending a RBF opted-in unconfirmed transaction today. So yes, a couple of clicks in a wallet such as Electrum, and you can "cancel" your payment by RBFing it back to yourself.

Is this full RBF feature going to be an optional feature, or is that the new norm for RBF-enabled transactions?

The default behavior will for nodes to have full RBF disabled, but nodes will be free to enable it if they so choose. The default may change to enabled in the future.

What I am asking is, can I use the "standard" RBF we have now or go with full RBF, or will their be no "standard" anymore?

If you opt in to RBF, then your transaction will definitely be replaceable as it is now. If you opt out of RBF, then some nodes will accept a replacement while others won't. Which transaction ends up being mined depends on how many nodes enable full RBF, how many miners are looking at nodes which enable full RBF, and a bit of luck.

What is the reasoning behind implementing this?

It prevents DoS attacks against multi-party funded transactions such as coinjoins and Lightning channels. There's more discussion about why this is the case in this thread: Full RBF

It could also require services that accept unconfirmed transactions to completely re-think their business model.

Correct.

Seems all that will be negatively affected if full RBF can't be deactivated manually.

You can disable full RBF on your node, but that doesn't mean you can start accepting zero confirmation transactions again if the rest of the network has enabled full RBF. Your node might reject the double spend transaction from its mempool, but that is irrelevant if the double spend transaction finds its way in to a block.

[NotATether]

I know everyone would like to think that including myself, but that is simply not true.

Why isn't it true? The Lightning Network works as a network of mini-VISA nodes. It is natural to can handle more transactions than VISA.

Yes they are mini-nodes, but the actual settlement is still dependent on the transaction confirmation time on L1. The payment is done instantly at the cost of delaying the L1 settlement, like a mortgage.

We can only batch payments as long as there are enough off-chain funds to finance the LN transactions.

Lets say LN become more popular and several thousands of channels are opened and closed on a single day. Since channels have to be constantly refilled, that means a lot of funding transactions are going to be made at once on any given day, leading to congestion on the L1 network reminiscent to times when exchanges were moving their funds around.

Basically, we are just swapping payment transactions with LN funding transactions on L1.

Maybe once the LN proves itself capable of holding very large funds (>$1000) in a single channel safely without counterparty risk, the funding transaction volume would slow down as people choose to keep their savings entirely on L2. But we haven't reached that phase yet.

[Pmalek]

<Snip>

If those DOS attacks you mentioned are a serious threat and something that has been happening, I can understand why the developers are trying to fix the problem in this way. Do we have any reports about how big of a problem this is? But I also think that it will cause a division in the community if the majority of nodes opt-in for Full RBF. The services and businesses I mentioned previously will suffer, and they will have to find a new way to retain their customers but without exposing themselves to being attacked with doublespends. Instant swaps become a thing of the past.   

[o_e_l_e_o]

Do we have any reports about how big of a problem this is? But I also think that it will cause a division in the community if the majority of nodes opt-in for Full RBF.

I don't, but I would recommend reading the three mailing list posts I linked to here for more information about the issue.

The services and businesses I mentioned previously will suffer, and they will have to find a new way to retain their customers but without exposing themselves to being attacked with doublespends. Instant swaps become a thing of the past.

True. There is a lot of ongoing discussion on this topic between the CEO of Bitrefill Sergej Kotliar and some of the devs, starting from here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021056.html. There have been various opinions raised, from "Zero confs were never safe to begin with" to "Use Lightning" to "The receiver can use CPFP". None of them seem entirely satisfactory.

[BlackHatCoiner]

Yes they are mini-nodes, but the actual settlement is still dependent on the transaction confirmation time on L1. The payment is done instantly at the cost of delaying the L1 settlement, like a mortgage.

Just as the payment of my debit card is done instantly at the cost of delaying the real-life L1 settlement, that is to reach the bank and hand over some cash.

Lets say LN become more popular and several thousands of channels are opened and closed on a single day. Since channels have to be constantly refilled, that means a lot of funding transactions are going to be made at once on any given day, leading to congestion on the L1 network reminiscent to times when exchanges were moving their funds around.

This is a description of the scaling problem. I never said Lightning scales the system by 100%. Also, provided that Lightning's capacity increases due to increase in number of users, we can safely presume that the number of stable channels (chiefly used by businesses) will rise as well.

Maybe once the LN proves itself capable of holding very large funds (>$1000) in a single channel safely without counterparty risk, the funding transaction volume would slow down as people choose to keep their savings entirely on L2. But we haven't reached that phase yet.

I don't think we'll ever reach this. Risks on keeping money in L2 will always be more than in L1.

[n0nce]

Maybe once the LN proves itself capable of holding very large funds (>$1000) in a single channel safely without counterparty risk, the funding transaction volume would slow down as people choose to keep their savings entirely on L2. But we haven't reached that phase yet.

I don't think we'll ever reach this. Risks on keeping money in L2 will always be more than in L1.

Except of course, if an L2 solution emerges and establishes itself, that doesn't require a hot wallet. Then there may even be L2-capable hardware wallets and the attack surface would be similar to a layer 1 wallet. I am hopeful!
I'm not too worried / in a rush though, since transaction volume is still very low nowadays, despite Bitcoin's high price.