A common chant from many in this space these days in response to any discussion of changes to the Bitcoin protocol is “Don't mess with Layer 1! You can just build it on Layer 2!” Sounds like a lot of common sense, doesn't it? Why risk the security and stability of L1 when you can build Above him?The problem is that this fundamentally fails to understand the relationship between the first class and the second class.
The L2 protocol is an extension of L1. Whatever the L2 is designed to do must eventually come down to what the L1 is capable of doing. The blanket phrase “Just do it on L2!” It obscures many implicit facts of what can or cannot be done on L2 given the current state of the underlying layer. For example, imagine you are trying to build a Lightning Network without multi-signature scripts. You can't. It would not be possible to share control between more than one person, and the whole concept of a payment channel would not be possible.
Development of payment channels
The whole reason payment channels exist in the first place is the fact that Bitcoin's L1 supports the ability for multiple people to share control of the UTXO using a multi-signature script. What is possible on L2 is inherently limited by what is possible on L1; Yes, of course it is possible to do things on L2 that are not possible on L1, but the ultimate limiting factor of what you can do off-chain is what is possible on-chain. Payment can only be confirmed faster in the payment channel because on-chain custody can be shared between multiple people.
Even this is not enough for a secure payment channel though. The original payment channel had a pre-signed transaction using nLocktime which refunds the funder after multiple blocks, and only supports one-way payment channels. The malleability of transactions has made these original payment channels unsafe to use. If the financing transaction is tampered with by someone before it is confirmed, the refund transaction will become void and the financier will have no way to claim his money back. The other party in the channel can effectively hold their funds hostage.
CHECKLOCKTIMEVERIFY, the ultimate time lock opcode, was the solution. CLTV allows you to make the coin unspendable until a certain block height or a certain time in the future. This, combined with the ability to create scripts that can be spent in multiple ways, allowed the multi-signature UTXO to have a script path where the financier can spend all the funds themselves after a specified period of time. This ensures that the financier will be able to claim a refund in the worst-case scenario even if the financing transaction is corrupt. However, the channel can still only facilitate payments in one direction.
In order to facilitate two-way payments, it was necessary to find a suitable solution for transaction scalability. This was a great incentive for the separate witnesses. A time lock is all that was necessary for a one-way channel because of the money Just Increase in one direction. The only risk to the sender was that the other party would never claim what had already been sent over the chain, leaving the rest of the sender's funds trapped. Timelock redemption gave the recipient an incentive to claim funds on-chain before the timelock, when they lost all funds already sent, and also gave the sender worst-case recourse in the event that something happened that took the recipient permanently offline. The script does not support charging certain amounts for certain future scripts, so a pre-signed transaction is the only viable initial refund mechanism if payments are going to flow both ways. This reopened the risk of funds being held hostage.
With the upgrade to Segwit, this issue has been resolved. Instead of a timely refund to incentivize honest behavior, a punishment switch was introduced. Since money in a two-way channel can flow back and forth in each direction, there is bound to be a situation where both sides had more money in the previous state of the channel than in the current state. By creating a branch on each pre-signed transaction for each channel instance with a penalty key, users can exchange it after signing the new instance and see if the other party tries to use an old transaction, they can claim 100% of the funds in the channel. Time locks are used to ensure the normal course of spending where users take their balances invalid for a period of time to give channel parties the opportunity to use the penalty key if necessary. However, there is a problem with this, using CLTV means that at some point in the future the channel will he have To close otherwise the time lock will expire and you no longer have this safety period to punish the dishonest party.
Two-way payment channels also need CHECKSEQUENCEVERIFY, or relative time locks, in order to solve this problem. Unlike CLTV, which specifies a specific time or height in the future, a CSV specifies a relative length of time or number of blocks of time or block at which the UTXO is confirmed using the CSV script in the blockchain. This allowed the safety period to operate to use the penalty switch without having to close the channels on the chain at a predetermined time.
Even that doesn't give us the accelerated network though. There is still no way to actually route payment across multiple payment channels. They can make payments in both directions, but only between the two people participating in the channel. In order to route payments across multiple channels, you need, you guessed it, other L1 functionality. Locked hash contracts are how this is achieved, and they require both CLTV as well as hashing. Hashlocks require the pre-hash image to be provided in order to spend coins. It's like a signature, except you're actually just revealing the “private key” instead of signing with it. This allows the recipient of a Lightning payment to provide a hash, and each intermediate channel between sender and recipient creates a script that allows instant spending using the pre-hash image, or reversible refund after a time lock. If the recipient reveals the hash, everyone can claim the money to forward the payment, and if not, the money can be claimed back and reversed without it being finalized.
So the accelerator network as it exists today is entirely dependent on it five The functionality is possible on the Bitcoin base layer. Multi-signature scripts, absolute timelocks, relative timelocks, separate witness, locks. Without any of these features at the first level, lightning as we know it today would not be the possible second level we could create. Its existence as an L2 depends entirely on the L1's ability to do certain things. So, if one had to do that, in a world with Bitcoin that doesn't support hashes, in-text time locks, and no fix for scalability, just go “just build a two-way, multi-hop payment channel system on Layer 2 !We shouldn't mess with the first layer, that would be a completely incoherent statement.
the hunt
However, strictly technically, it is still possible to build a two-way, multi-hop channel system in that world without those three features of L1. In a particle The cost in terms of promoting trust in others so they don't steal your money when they are able to do so. Federation sidechain. Everyone could have created a monochain like Liquid or Rootstock and added those features to the sidechain, building the Lightning Network there instead of the mainnet. The problem with that is that it's not the same thing. On a technical level, the network will work exactly the same way, but no one using it will have the same degree of control over their coins.
When they shut down the Lightning Channel, it will rest on a consortium-backed sidechain, meaning it will just be an accounting entry on top of someone else's multisig wallet since you can't control those coins on L1. You just have to trust the distributed group running the federation not to fool everyone. Even chains of command (which themselves, ironically, require implementing new L1 functionality) are just another form of federation at the end of the day, with some additional constraints added to the checkout process. The union is just miners and not people holding private keys.
This is the implicit truth, whether they understand it or not, behind the reaction “Just build it on L2!” When someone discusses improvements to L1. There is the scope of what can actually be built on L2, which is somewhat limited and constrained by its own scaling constraints, and then there is the scope of what is not actually possible. It is impossible to build everything that falls into the latter category without interfering with a trusted entity or group of entities that ultimately controls users' funds for themselves.
what is the point?
“Second Layer” is not a magic spell. You can't just wave a magic wand and chant words and anything and everything magically becomes possible. There are strict, unavoidable limitations to what the second level can achieve, and these limitations are what the first level can achieve. This is just an inherent fact of engineering reality when looking at a system like Bitcoin. You can't escape it in any way except by degrading trust assumptions more and more the more level 2 flexibility you build beyond the capabilities of level 1.
So, when having discussions about these issues, such as what improvements can be made to the first language, two things are of paramount importance. First, these improvements to the L1 are almost entirely centered around enabling the construction of more flexible and scalable L2 languages. Second, L2 cannot magically enable everything. L2s have their own limitations based on those in the L1, and having a discussion regarding changes in the L1 without acknowledging that the only way to overcome these limitations is to introduce authoritative entities is not an honest conversation.
It is time to start acknowledging reality if we are going to discuss what to do with Bitcoin in the future, otherwise nothing will happen but denial and gaslighting of reality. This is not a product.
