Bitcoin Forum

nothing to see here

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.

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

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

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.

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

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.

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.
 

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.

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.

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

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.

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.

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.

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.

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.

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

That somewhat is sufficient enough for a global scale.

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.

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

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.

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.

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.

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 (https://bitcointalk.org/index.php?topic=5403730.0)

Correct.

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.

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.

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.   

I don't, but I would recommend reading the three mailing list posts I linked to here (https://bitcointalk.org/index.php?topic=5403730.0) for more information about the issue.

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.

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.

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.

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! :D
I'm not too worried / in a rush though, since transaction volume is still very low nowadays, despite Bitcoin's high price.

That basically means an L2 solution where nodes can disconnect from the internet for long periods of time without losing state. It's hard to do that without a central [group of] node(s) or a distributed blockchain similar to L1.

I mean, let's see how satellite internet goes first. Bitcoin itself was only possible because of the internet and TCP & UDP connections.

Yes, exactly. Decentralization should definitely be kept, but without simply building a blockchain on a blockchain, with PoW and everything.. ;) It's a tough problem.
If it was possible to achieve the same amount of decentralization, security and ability to go offline, it could just as well be implemented on L1. So there will need to be some compromise, in exchange for faster and cheaper transactions.

Maybe some relatively small amount of trust placed in a decentralized (but less than L1) group of nodes and additional timelocks which require you / your watchtower (or similar concept) to go online once a month or some really long time interval like that.

What does satellite internet have to do with Bitcoin scaling?
In my humble opinion, internet for the masses will always be on the ground.

One satellite can only serve so many customers, and just adding more doesn't work. Not only due to the Kessler syndrome (https://en.wikipedia.org/wiki/Kessler_syndrome), but also due to the astronomical cost of satellite launches and maintenance.

Right now, Starlink's 3000 satellites (https://en.wikipedia.org/wiki/Starlink) provide 500,000 people with internet. Let's say they can do 600k, that's only 200 base stations per satellite. Even if we only needed 1 billion base stations to serve the whole planet, it would require 5 million satellites; I hope it's easy to see how even a tenth or a hundredth of that is technically impossible.

The only case wherein a Layer-2 solution has the equivalent attack surface of Layer-1 is a Layer-2 solution with zero added risks. Layer-2 migrates the same risks Layer-1 does, plus some extra. It's true provided that Layer-2 operates in the same decentralized, trustless manner. Liquid, for example, doesn't fit here, because it requires faith to federations.

There is work done on airgapped Lightning ownership (https://bitcointalk.org/index.php?topic=5414245.msg60974342#msg60974342), but as far as I can tell, the added risks are far from 0.

Transaction capacity and hash rate have nothing to do with each other. As an aside, this is why all the articles/people saying "Bitcoin uses so-and-so much energy per transaction" is nonsensical because hash rate (or power usage) is in no way connected to transaction capacity.

Transaction capacity has to do with the amount of data sent to and stored on the blockchain, not the number of hashes processed by mining machines. Two completely different systems in Bitcoin.

Only way to increase transactions is to increase the amount of data being processed by, and stored to, the Bitcoin network.

There are two levers to change this: the block time and the block limit. But increasing the data sent to Bitcoin would at some point affect the operation of the network by creating many more orphaned blocks as well as hurting decentralization by making it harder and more expensive to run nodes. And Bitcoin's utility is essentially entirely based around its decentralization. That's where all its revolutionary features come from and that is a lot of what separates it from every other cryptocurrency out there. Crypto chose to abandon what makes Bitcoin strong in order to have more transactions. Bitcoin stayed unique and irreplaceable by being the first and only cryptocurrency totally committed to be really f**king good money and decentralization is an absolute requirement for that.

Just look at Ethereum. It has to do much faster transactions and more transactions and has to handle much more data due to smart contracts. And the operation of its nodes are very centralized, plus now with PoS its transaction validators are very centralized as well. A lot of the Ethereum network runs off AWS because it is too much of a hassle to run your own nodes, and there are not a whole lot of full archival nodes that the network relies on because the requirement are too high for the average Ethereum crypto super user.

Now could Bitcoin change one or both of those levers a bit (block time and block limit) to increase transactions? Sure. It's not like changing it a bit is going to suddenly destroy Bitcoin's decentralization. It'd be weakening Bitcoin's decentralization on a sliding scale, so if you didn't change the numbers too much Bitcoin would still be extremely decentralized, just a bit less so. But that would require a hard fork and one of the main facts that makes Bitcoin extremely good money is that it is immutable: it doesn't hard fork. This was the debate in 2017 that led to little sections of the community breaking off to create the sh*tcoin BCH, which then further broke into BCH and BSV, both of which are completely irrelevant. Meanwhile Bitcoin soft-forked with Segwit and remained immutable.

And what would be the upside to hard forking Bitcoin to get more transactions? What maybe you like 4x the number of transactions. Okay great then Bitcoin can handle like 20 tx/s which is still nothing compared to secondary networks in the finance world so you're still left with a Bitcoin network that can't handle much on the base layer, but you've broken Bitcoin's promise of immutability and made the whole network less decentralized and therefore weakened every use case for Bitcoin.

All payment systems have a secure slower base layer and then build more efficient networks on top. You compare Bitcoin to VISA. VISA is not a base layer network for fiat transactions. The base layer is like Fedwire or something and it is much much slower. VISA is a secondary network. So if you want to compare Bitcoin to VISA you have to make the comparison with the LN. LN is, so far, the main network built on top of bitcoin for more efficient payments. It's VISA vs Bitcoin LN, not VISA vs Bitcoin. And LN is both much cheaper and much faster than VISA, though granted it still needs a lot of work to be ready for mass usage.

Side note, is VISA even the fastest transaction settler anymore, or has it been overtaken by competitors such as Paypal or possibly even UnionPay?


This would have to be ruled out for reasons that you wrote, making the only possible strategy to scale Bitcoin transactions is by using a (possibly more centralized) Layer 2 network.

Yup that's the whole point. That's why Bitcoiners rejected the idea of turning Bitcoin into a s**tcoin when BCH broke off and fell into obscurity. You don't scale a blockchain on L1. All that does is make it weaker. Just look at every single other cryptocurrency to see this.

L2 is where you scale blockchains. Same as any other payment rails the world uses. Security is on the base layer, transaction capacity is built into higher layers. Which is why we have the Lightning Network. And who knows there may be other L2 implementations built on Bitcoin in the future, but LN already provides better features than VISA does.

To explain further: you can't scale L1 essentially without L2. SegWit did help a little bit, but since scaling is "making transactions' size less" and NOT "making number of transactions per block more", to scale you need to figure out a clever way to settle transactions, provided that they take the minimum size on-chain. The answer is: do it off-chain. Two on-chain transactions can equate to nearly infinite transactions now more. This means that the size of all these transactions divided by the size of the two multi-sig transactions increases abruptly.

I've always contended that Segwit was never intended to be a scalability solution or even a band-aid in the first place. It had a specific problem to solve - transaction malleability - and solved that by disabling some parts of the transaction, so then they had to figure out how to remove the charges for the dead bytes in transactions.

Changing these things on Bitcoin is like trying to switch a motor from a plane that is flying at full speed. The game theory involved requires that everyone is onboard. Many tried in the past and failed. The fact that you cannot easily change Bitcoin to "go faster" or "be cheaper" and whatnot gives it value since certainty has value even if at the cost of slower more expensive transactions.

Plus not many people, especially newbies, have considered that it's about settlement assurances. Other blockchains might be "faster", but the settlement assurances are lower. If compared to Bitcoin, 1 confirmation would be equal to 50 or more confirmations for that other blockchain, neutralizing the "advantage" because Bitcoin blocks have more accumulated miner-costs.