Topic: please delete (Read 515 times)

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.

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.

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.

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.

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.

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.

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.

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, but as far as I can tell, the added risks are far from 0.

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, but also due to the astronomical cost of satellite launches and maintenance.

Right now, Starlink's 3000 satellites 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.

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.

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.

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.

I don't, but I would recommend reading the three mailing list posts I linked to here 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.

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.   

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.

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

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.

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.

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.

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.

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.