From the point of view of an application developer, it is for now much easier to use layer 1 features.
This is due to being able to externalize your burden on the network.
1. Hey nodes, will you do my job?
Blocks are expensive to produce
You don't need to have much DOS concerns in your application if you are only reacting to onchain payments. But what happens if you do an expensive operation each time your Lightning node accepts an HTLC ?..
Backups are simple
You don't have to think much about backing up the state of your application for your user: your data is public and stored by everyone. Your user only has to back up a very small amount of data.
On Lightning, you are responsible for your own data. That's sometimes surprising to users who have been accustomed to (ab)using the block chain for years :).
In addition, on Lightning in its current form you are in a pretty bad position should you miss a single state backup. But this may be fixed in the future.
The security model is simple(r)
Even if there are some pitfalls and idiosyncrasies in Bitcoin, it's way harder to reason about assumptions you can reasonably make for your software and what you can convey to your user is a reasonable usage of your software.
For instance, "may i allow my user to re-import their HD wallet master account in another wallet?"
- Bitcoin onchain: sure, what could go wrong?
- Bitcoin offchain: meh. It's not that simple.
The same goes with "may i dig a hole, put my wallet in there, come back in a year, and still be in full possession of my coins ?"
- Bitcoin onchain: sure, what could go wrong?
- Bitcoin offchain: meh. It's not that simple.
Bootstrapping is simpler
Even if we usually make the analogy to "send coins to", Bitcoin onchain did not require interactivity. Just send the transaction to every single node on the network, make them verify it for you and call it a (lazy) day.
Now with Lightning for someone to start paying they need to find a way to connect to the payee, actually making the above analogy closer from the truth as they are actually transferring data.
For someone to start receiving payments, they also need to "be able" to be paid (have enough inbound liquidity).
Payments get increasingly more secure
Under Lightning's assumptions, a payment will be almost instantly "secure" :tm:
In practice, arguably even more so than a handful of onchain confirmations. However, maybe not more than a hundred. Or not than a thousand, or ten thousands confirmations.
For some applications (such as making very large payments), you may want to use this feature unique to the block chain: don't consider a payment to be made until a reorganization of the block chain that deep would put the entire currency down anyway.
2. Hey nodes, can you be more qualified at my job?
Of course, there are also drawbacks to (ab)using the chain.
Decent payment security is slow to bootstrap
Getting the first confirmation may be infinitely longer than on a layer 2 system. If you ask "if my payment can go through successfully, when is it going to be finalized?":
- Bitcoin Lightning: immediately. (this assumes unstuck payments)
- Bitcoin onchain: well, lemme explain you the block space market.
UTXO management
This logic is one you can't outsource to the nodes :). It's pretty difficult optimization problem that highly depend on the usage that is going to be made of your software. It takes a deep understanding of the tradeoffs and knowledge of the existing solutions to the developer to make a sensible decision.
On Lightning, you don't have to manage coins. The value is similar to a flux rather than to actual physical, indivisible coins.
Fees orthogonal to payments and fee management
Onchain fees depend on the actual transaction (in the database sense of the term) size, not on the actual payment. They are in addition very unreliable, in theory you really can't know for sure that your transaction is going to make it into a block in advance. You are really hoping for the best.
The counter measures for adapting to this always-moving block space market incur an additional cost in knowledge and understanding (and complexity of implementation) to the application developer, similarly to coin selection (which is tightly related).
"how much is my finalized payment going to cost me?":
- Bitcoin Lightning: a proportional fee of
x sats per million of sats transferred and a fixed fee of y.
- Bitcoin onchain: well, lemme explain you the block space market.
Higher usage cost
As the demand for the finite resource of block space increases, so are average fees premium to be included as soon as possible in the chain. This makes some design of application not possible onchain anymore, re-aligning the incentives of (ab)using the network to incur less burden to the software / user of the software.
Lack of features
Onchain nodes are pretty restricted in what they can verify for you. Some more complex systems can be emulated on a L2 network with different trust assumptions than the base trustless network (eg with sidechains).
The advantage of not doing it onchain here is that it's opt-in: you don't have to make the entire network and economy accept to augment their functionalities in order to bear even more burden than previously.
Some features may be either backward incompatible or present tradeoffs that not everyone would accept. Their addition to the base layer would raise big questions about the censorship resistance of the system and finally the point of using it in the first place.
