Layer 2 is not a magic spell
A common cry from many in the space these days in response to discussions about Bitcoin protocol changes is “Don’t touch layer 1!” Just build on Layer 2!” This seems like a very logical thing to do. Yes? Why risk the security and stability of L1 when you can build on top of it? The problem is that this fundamentally fails to understand the relationship between layer 1 and layer 2.
The L2 protocol is an extension of L1. Everything that the L2 is designed to do must ultimately be reduced to what the L1 can do. This is a blanket statement: “Just do it in L2!” By taking into account the current state of the base layer, we obfuscate many implicit realities about what can and cannot be done in the L2. For example, imagine trying to build a Lightning Network without a multi-signature script. You can’t. It is impossible for more than two people to share control, and the whole concept of payment channels is also impossible.
Evolution of payment channels
The reason payment channels can exist in the first place is because Bitcoin’s L1 supports the ability for multiple people to share control of UTXOs through multi-signature scripts. What is possible in L2 is inherently limited by what is possible in L1. Yes, of course you can do things in L2 that are impossible in L1. But what ultimately limits what can be done off-chain is what is possible on-chain. On-chain management can be shared by multiple people, allowing for faster payment confirmation across payment channels.
But that alone is not enough for a secure payment channel. The original payment channel had pre-signed transactions using nLocktime time locks, which returned money to the funder after many blocks had occurred and supported a one-way payment channel only. Due to their transaction flexibility, it was not safe to use these original payment channels. If the funds transaction is tampered with by anyone before it is confirmed, the refund transaction will be void and the funder will have no way to get their funds back. The other side of the channel can effectively hold your money hostage.
CHECKLOCKTIMEVERIFY, an absolute time locking opcode, was the solution. CLTV allows you to make coins unusable until a certain block height or some future time. This, combined with the ability to create scripts that can be used in a variety of ways, allows multisig UTXOs to have a script path that allows funders to spend all their funds directly after a time lock. This ensured that if a funding transaction went wrong, the funder would get their money back in the worst-case scenario. However, channels can still only enable one-way payments.
To facilitate two-way payments, an appropriate solution for transaction flexibility was needed. This was a huge motivation for Segregated Witness. A time lock is all that is needed for a one-way channel. Only It increased in one direction. The only risk for the sender is that the other party never charges what they have already sent on chain, leaving the sender’s remaining money trapped. Timelock refunds gave recipients an incentive to claim funds on-chain before the timelock. In this case, all funds already sent will be lost, and the sender will have no choice but to bail out in the worst-case scenario if something happens to take the recipient permanently offline. . Scripts do not support applying a specific amount to a specific script in the future, so pre-signed transactions are the only viable initial refund mechanism if payments go both ways. This again created the risk of funds being held hostage.
Upgrading to Segwit fixed this issue. Penalty keys were introduced instead of time-locked refunds to encourage honest behavior. Because funds in a two-way channel can flow back and forth in both directions, it inevitably happens that both sides have more funds in the previous state of the channel than in the current state. By using penalty keys to set points on pre-signed transactions in each channel state, users can exchange them after signing a new state, and claim 100% of the funds from the channel if the other party attempts to use the old transaction. You can see that it exists. Time locking is used to ensure that the normal spending path through which users take their respective balances is invalid for a period of time, giving channel parties the opportunity to use penalty keys if necessary. But there’s a problem. Using CLTV means that at some point in the future the channel will have Otherwise, the time lock expires and there is no longer a safe period to punish the dishonest party.
To fix this, bidirectional payment channels also needed CHECKSEQUENCEVERIFY or relative time locks. Unlike CLTV, which specifies a specific time or block height in the future, CSV specifies the length of time or number of blocks relative to the time or block at which the UTXO using CSV in the script will be confirmed on the blockchain. This allowed a safety period for penalty key usage to operate without the need to close the on-chain channel at a predetermined time.
But this doesn’t give us the Lightning Network. In fact, there is no way yet to route payments through multiple payment channels. Payments can be made in both directions, but only between the two people involved in the channel. It is expected that routing payments across multiple channels will require other features of the L1. A hash time fixed contract is how this is achieved and requires both a CLTV and a hashlock. Hashlock requires a pre-image to be provided to the hash in order to use the coin. It’s like signing, except that instead of actually signing, you reveal your “private key”. This allows the recipient of a Lightning payment to provide a hash lock, and any intermediate channel between the sender and receiver generates a script that can spend the money immediately with the hash pre-image or reversely refund the money after a time lock. If the recipient makes the hashlock public, anyone can claim the money for delivery of the payment, otherwise the money can be reverse charged or canceled without final confirmation.
Therefore, the Lightning Network as it exists today is entirely dependent on: five The functionality is possible in Bitcoin’s base layer. Multi-signature scripts, absolute time locks, relative time locks, separated witnesses, and hash locks. If any of these features weren’t present in the L1, Lightning as we know it today wouldn’t be the L2 we can build on. Its existence as an L2 depends entirely on the L1’s ability to perform certain tasks. So, in a world where Bitcoin doesn’t support hash locks, timelocks in scripts, or malleable modifications, go “Build a two-way multi-hop payment channel system at Layer 2!” We can’t mess with Layer 1.” This would be a completely inconsistent statement.
catch
That is, strictly speaking, it would still have been possible to build a two-way multi-hop payment channel system in that world even without the three features of L1. to exorbitant It’s the cost of building trust so that someone else doesn’t steal your money when they can. Federated sidechain. Anyone could set up a federated chain like Liquid or Rootstock and add its functionality to the sidechain, building the Lightning Network instead of the mainchain. The problem is that they are not the same thing. At a technical level, the network works exactly the same, but people using it don’t actually have the same level of control over their coins.
If they close the Lightning channel, they will settle on a federation-backed sidechain. In other words, it’s just an accounting entry on top of someone else’s multi-signature wallet with no control over those coins at L1. To avoid looking down on everyone, you have to trust the decentralized group that runs the federation. Ironically, even the drive chain that is supposed to perform the new L1 functions on its own ends up being just another form of federation, which adds some additional restrictions to the withdrawal process. Federations are just miners, not holders of private keys.
This is the implicit reality, whether understood or not, that underlies the response “Just build it in your L2!” Whenever someone discusses L1 improvement. There is already scope for what can be built on L2, some of which is somewhat limited and limited by its own scaling limitations, and there is scope for it not yet possible. Anything that falls into the latter category is impossible to build without involving a trusted entity or group of entities that ultimately controls user funds.
What is the point?
‘Layer 2’ is not a magic spell. You can’t just wave a magic wand and memorize words and everything magically becomes possible. There are unavoidable hard limits to what L2 can achieve, and these limits are what L1 can achieve. This is just an inherent fact of engineering reality when looking at systems like Bitcoin. As the L2 becomes more and more flexible, building beyond the capabilities of the L1, this cannot be avoided in any way other than by degrading the trust assumption.
Therefore, when discussing these issues, such as what improvements can be made to the L1, two things are most important. First, these improvements to L1 are almost entirely focused on enabling more flexible and scalable L2 deployments. Second, L2 can’t magically activate everything. L2 has inherent limitations that build on the limitations of L1, and discussing changes to L1 without acknowledging that the only way to address those limitations is to introduce trusted entities is not an honest conversation. .
If we’re going to discuss what to do with Bitcoin going forward, it’s time to start acknowledging reality. Otherwise, nothing happens except denial and gaslighting of reality. And that’s not productive.
