reply on: Rethinking Lightning \ stacker news ~bitcoin

13.2k sats \ 17 replies \ @niftynei 7 Jan \ on: Rethinking Lightning bitcoin

Fundamentally, all current lightning channels could become entirely useless if on-chain fees went high enough because a single payment would require too many reserves.

All layer two designs suffer the same problem.

Fundamentally, transacting off-chain is going to be beneath “economic feasibility (if questioned)” for the median user.

Attempts to build larger coin pools suffer from exit-ability and consensus problems (how do people agree on the state of the L2 accounts to consider it valid?). I don’t expect this to ever change, no matter what new primitives get forked in or protocols for “sharing utxos” get invented.

Choosing fedimints is deciding on one set of tradeoffs (no supply auditability, risk of jurisdictional kyc ban hammer for federation withdrawals) — every choice has different drawbacks. There is literally no “best” solution. Saying you’ve found one without enumerating the tradeoffs isnt very useful imo for helping people understand the problem space.

110 sats \ 4 replies \ @anon 7 Jan

Drivechain doesn't suffer from that.

1491 sats \ 2 replies \ @benthecarman OP 7 Jan

Drivechains just kill bitcoin incentive models

150 sats \ 1 reply \ @anon 7 Jan

You mean the incentive to only use Bitcoin through a handful of centralized KYC regulated custodians?

Yeah, Drivechain kills that.

266 sats \ 0 replies \ @1fatmess 7 Jan

Fuck Drivechain.

1282 sats \ 0 replies \ @anon 7 Jan

Drivechain is just big blocks in a different way. It doesn’t solve the scaling issue, it just moves it to a new location and replaces user keys with miner votes. But the scaling problem remains the same, and largely dumps it on miners who now have the explicit option of voting on something they don’t even have to verify. Then it tries to hide the fact that it doesn’t really solve anything, behind a 6 month time lock… which is the entirety of its real attempt at securing ownership, hoping that 6 months is long enough to enforce whatever the truth was if there are no validators when things go wrong.

But that only exposes the problem rather than fixing it, you could just slap a 6 month timelock on literally any L2 and then say “see, what are the chances the rightful owner doesn’t get their funds now?”

351 sats \ 8 replies \ @tomlaies 7 Jan

Fundamentally, all current lightning channels could become entirely useless if on-chain fees went high enough because a single payment would require too many reserves.

All layer two designs suffer the same problem.

I'm a little shocked that such blatant fud-propaganda slips by here without anybody refuting it.

All L2 solutions - including Lightning - don't suffer from this problem. They solve this problem.

First of all the Fees of L1 onchain Bitcoin a result of demand and supply. Lightning payments can be done instantly, in arbitrary sizes and between many (basically endless) clients. This tips the scale. It tips the scale with huge resources on the supply side. The reason why this effect hasn't fully kicked in yet is because not every exchange, miner, bitcoin business isn't on Lightning yet.
Second Lightning enables users to ignore on-chain fees. Make your fiat-Bitcoin exchange on an exchange and withdraw via lightning. Use your money on a Bitcoin business that accepts Lightning. Normal people need zero interaction with onchain. In the future they wouldn't even need to know what onchain even is just like many people in the fiat world don't know what swift is. The reason why this effect hasn't fully kicked in yet is, again, because not every exchange, miner, bitcoin business isn't on Lightning yet.

145 sats \ 0 replies \ @niftynei 7 Jan

Honestly, i love your optimism

if the bitcoin chain wasn’t being filled with what im politely terming “extra-chain assets” but instead transfers of bitcoin you might have a stronger point wrt supply + demand of blockspace and on- vs off- chain fees

264 sats \ 0 replies \ @vindard 7 Jan

Second Lightning enables users to ignore on-chain fees.

Yea you should really re-read the original post. This isn't at all true, and it's explained pretty well why

52 sats \ 2 replies \ @ek 7 Jan

Second Lightning enables users to ignore on-chain fees.

Did you read the post? Maybe you mean users using custodial services with "normal people" here:

Normal people need zero interaction with onchain.

LN is an abstraction that has leaks as explained in the post (and like many abstractions).

Maybe we're arguing about different things but do you not see the leaks?

13 sats \ 1 reply \ @tomlaies 7 Jan

I'm answering specifically on the framing as Lightning being at the whims of the economics instead on Lightning being what determines the economics.

Let's take the example of global container shipping. Sure you can say the shipping industry is at the mercy of freight rates of the market economy. But that's undercomplex perspective at best and dishonest at worst. Global shipping isn't at the mercy of the economy, it's part of what fundamentally drives the economy.

3 sats \ 0 replies \ @ek 7 Jan

Global shipping isn't at the mercy of the economy, it's part of what fundamentally drives the economy.

I would say global shipping depends and drives the economy.

It's a complex system where some outputs can be inputs again (feedback loops).

0 sats \ 2 replies \ @_b_o_n_e_s_ 7 Jan

the post is saying that channels are affected by fees as channels need reserves, then you're saying they don't, why not?

0 sats \ 1 reply \ @tomlaies 7 Jan

They are right now but in the long term it's the other way round. Channels will affect the fees more than fees will affect the channels.

100 sats \ 0 replies \ @_b_o_n_e_s_ 8 Jan

and how do we get to the long term if the near term is unclear if lightning is even the right way to scale

10 sats \ 2 replies \ @john_doe 7 Jan

Do you know a good post or article writing about these tradeoffs for each solution? (Lightning, ecash, etc)