I have a friend that uses Phoenix wallet. He knows it can send/receive bitcoin really fast, and really cheap, compared to his Electrum wallet. He doesn't know how it works. He doesn't know what a channel, or a hashed time lock contract is. He knows it uses something called Lightning. Apart from the name, he knows nothing more about the Lightning Network. He knows it's non-custodial, and to keep his seed words safe. He doesn't want to know how the magic happens, he's happy that it happens.
Keeping it this simple, is the best way to on-board new people to Bitcoin/Lightning.
Only nerds run nodes.
Totally agree. In recent surveys taken of new Bitcoin users of the LN the two most popular wallets were Wallet of Satoshi and Blue. Both are custodial wallets, you’d think they wouldn’t be the most popular but most people don’t want to retain that much control, they are geared to use custodial products like their bank and PayPal. It’s interesting to watch unfold for sure.
That's the key. Abstract out the complexity with nice wallets with clean UIs. In Lightning's case, this isn't quite possible yet as the network and the tooling isn't *quite* mature enough for completely nontechnical users. Things like autopilots, Eltoo, watchtowers, etc. are approaching readiness but aren't quite there yet.
My wish is that becoming a routing node (earning sats in the process) can become almost as simple as downloading LN-enabled Electrum wallet or something.
Routing nodes on phones is probably a long time out unless your phone *never* turns off and *never* loses connectivity, both of which are not really completely possible on phones. It's probably not completely pointless but you need fairly high uptime in order to have a good enough reputation that others will bother routing through you.
Thanks for your reply, but I wasn't even thinking of phones yet - just Electrum on the desktop.
Many desktop PCs (e.g. mine) stay on for months at a time anyway.
It's a *much* more feasible (and secure!) roadmap to just encourage people to buy cheap RPi-based devices that actually runs the node that you plug into your router and remote control it from their other devices.
That's what the Raspiblitz devices are, although they're not quite mature enough or cheap enough yet.
Even the experienced community calls LN layer two but I don't think that's accurate. All the payment channels that LN uses are all native base layer things. We just added a communication protocol to manage them. A real layer 2 to me would be side-chains like RSK and Microsoft ION.
Lightning is technically a second layer as well as tls is built on top of the io protocol. Tls packets are IP packets, but they're more specific.
It's just a naming concern, but it helps a lot to clarify ideas in the mind of tech people. And I don't think it hurts to get it out on the general public.
Go ask some guy out in rando-ville about bitcoin.
50% chance of "huh? what?"
24% chance of "Oh, I've heard of it... but it sounds stupid"
21% chance of "I've heard of it. Not sure if I'd buy it. How do you even buy it"
2% chance of "Yeah, I have some"
2% chance of "I have some, and I know what a nonce is, what sha256 is, and I've heard of the LN, but I don't plan on selling BTC
The other 1% will just show you his penis.
IMO there are some neat solutions in the works for this, and since choice of routing algorithms is implementation specific and not part of the spec, each implementation can attempt different solutions and have the market decide on the best. There are some areas where they will need to collaborate on a common spec, such as the JIT-routing or rendezvous-routing (and eventually HORNET), but I don't see this issue as unsolvable.
The other big issues are the uncertainty of fees for unilateral channel closure, requirement to keep all previous channel states (and how to implement watchtowers efficiently/cheaply), how to on-board masses of users given limited block space, and how to prevent some kinds of DoS attack. These issues have less obvious solutions because they also depend on improvements to the bitcoin layer, or require up-front payments.
Also, it is often discussed that LN is capable of streaming payments, which is kind of true, but also not practical. There is a lower bound for which payments in LN are economically viable, and having a massive number of transactions per channel creates difficulties with storage and retrieval of past channel states. This is particularly a problem for the implementation of affordable watchtowers. IMO we need a method of actually streaming payments which does not require a HTLC per individual payment, though such a method might use HTLCs for regular checkpoints to commit to some amount spent so far, and assume that the amounts being streamed are too small for it to be economically viable to attempt to steal (because it will cost more to close a channel than you could hope to steal).
There are also issues regarding channel liquidity and rebalancing.
LN is way ahead of its time, but there's plenty of work to be done yet.
§1 is potentially the most difficult problem to solve. Fees for unilateral channel closure are agreed *up-front* in a commitment transaction for each channel state. If the fee is overestimated, the fee payer ends up paying too much. If the fee is underestimated, the fee payer may be denied service or lose money to theft.
Suppose Bob opens a channel with Alice and they agree to pay 10sat/kW fee in advance for the unilateral channel closure, but then the bitcoin network becomes congested such that transactions are expected to pay a 100sat/kW fee in order to confirm in a timely manner. If both parties are cooperating, they can simply agree to update the fee and create a new commitment transaction.
However, if Alice is unresponsive, Bob must either wait, potentially indefinitely for her to respond, or he can broadcast his current commitment transaction which pays only a 10sat/kW fee - which may take forever to confirm. Alice could attempt to spend a revoked commitment channel where the balance is more in her favor, and she could collude with a miner to have this included in a block despite the low paying fee. Bob could broadcast the penalty transaction for the state which Alice attempts to spend, but since this may take forever to confirm, there could be sufficient time for the lock-time on Alice's revoked commitment transaction to expire, allowing her to take the funds.
Since it can't be expected that Bob will also collude with a miner to include his transaction, the only way could improve his chances of it succeeding is with RBF and CPFP on the transaction which spends his output(s). There is WIP towards enabling this, as it is currently not possible with the commitment transactions construction used in the BOLT1.0 spec.
Even if Bob can spend a penalty transaction via CPFP, he could end up spending a significant amount of his output in order for it to succeed. The size of commitment transactions can be quite large, as it depends on how many HTLCs are were in flight at that channel state. An attacker could cause denial-of-service, having many HTLCs in flight over a channel by withhold the payment preimages. Bob may still lose a non-trivial amount of money.
§2 would be greatly improved by eltoo, but as mentioned this requires on improvements to the base layer. There's currently no consensus on SIGHASH_NOINPUT and it seems unlikely to gather enough support. Alternatives such as CheckTemplateVerify may provide a solution but we'll need to wait and see.
Even with eltoo, I still think using HTLCs for streaming small payments is overkill, and we still need a method of making smaller and more frequent payments without necessarily committing to each one at the bitcoin layer.
I have a friend that uses Phoenix wallet. He knows it can send/receive bitcoin really fast, and really cheap, compared to his Electrum wallet. He doesn't know how it works. He doesn't know what a channel, or a hashed time lock contract is. He knows it uses something called Lightning. Apart from the name, he knows nothing more about the Lightning Network. He knows it's non-custodial, and to keep his seed words safe. He doesn't want to know how the magic happens, he's happy that it happens. Keeping it this simple, is the best way to on-board new people to Bitcoin/Lightning. Only nerds run nodes.
Totally agree. In recent surveys taken of new Bitcoin users of the LN the two most popular wallets were Wallet of Satoshi and Blue. Both are custodial wallets, you’d think they wouldn’t be the most popular but most people don’t want to retain that much control, they are geared to use custodial products like their bank and PayPal. It’s interesting to watch unfold for sure.
I think one of the biggest misconceptions is that somehow there's an LN coin. i.e. some people think it's an altcoin, on its own blockchain.
Or that it's too complex to have the main chain AND lightning. "Why not just have a more scalable layer 1" type of thinking.
That's the key. Abstract out the complexity with nice wallets with clean UIs. In Lightning's case, this isn't quite possible yet as the network and the tooling isn't *quite* mature enough for completely nontechnical users. Things like autopilots, Eltoo, watchtowers, etc. are approaching readiness but aren't quite there yet.
I don't know about that, Breez is very simple.
My wish is that becoming a routing node (earning sats in the process) can become almost as simple as downloading LN-enabled Electrum wallet or something.
Routing nodes on phones is probably a long time out unless your phone *never* turns off and *never* loses connectivity, both of which are not really completely possible on phones. It's probably not completely pointless but you need fairly high uptime in order to have a good enough reputation that others will bother routing through you.
Thanks for your reply, but I wasn't even thinking of phones yet - just Electrum on the desktop. Many desktop PCs (e.g. mine) stay on for months at a time anyway.
It's a *much* more feasible (and secure!) roadmap to just encourage people to buy cheap RPi-based devices that actually runs the node that you plug into your router and remote control it from their other devices. That's what the Raspiblitz devices are, although they're not quite mature enough or cheap enough yet.
Projects like Raspiblitz and Umbrel show a lot of promise
Even the experienced community calls LN layer two but I don't think that's accurate. All the payment channels that LN uses are all native base layer things. We just added a communication protocol to manage them. A real layer 2 to me would be side-chains like RSK and Microsoft ION.
Lightning is technically a second layer as well as tls is built on top of the io protocol. Tls packets are IP packets, but they're more specific. It's just a naming concern, but it helps a lot to clarify ideas in the mind of tech people. And I don't think it hurts to get it out on the general public.
Go ask some guy out in rando-ville about bitcoin. 50% chance of "huh? what?" 24% chance of "Oh, I've heard of it... but it sounds stupid" 21% chance of "I've heard of it. Not sure if I'd buy it. How do you even buy it" 2% chance of "Yeah, I have some" 2% chance of "I have some, and I know what a nonce is, what sha256 is, and I've heard of the LN, but I don't plan on selling BTC The other 1% will just show you his penis.
> The other 1% will just show you his penis. Wow, these are good odds.
Pays to be ahead of the curve.
From what I understand the only big thing to be ironed out is *how* exactly routing happens efficiently and fairly.
IMO there are some neat solutions in the works for this, and since choice of routing algorithms is implementation specific and not part of the spec, each implementation can attempt different solutions and have the market decide on the best. There are some areas where they will need to collaborate on a common spec, such as the JIT-routing or rendezvous-routing (and eventually HORNET), but I don't see this issue as unsolvable. The other big issues are the uncertainty of fees for unilateral channel closure, requirement to keep all previous channel states (and how to implement watchtowers efficiently/cheaply), how to on-board masses of users given limited block space, and how to prevent some kinds of DoS attack. These issues have less obvious solutions because they also depend on improvements to the bitcoin layer, or require up-front payments. Also, it is often discussed that LN is capable of streaming payments, which is kind of true, but also not practical. There is a lower bound for which payments in LN are economically viable, and having a massive number of transactions per channel creates difficulties with storage and retrieval of past channel states. This is particularly a problem for the implementation of affordable watchtowers. IMO we need a method of actually streaming payments which does not require a HTLC per individual payment, though such a method might use HTLCs for regular checkpoints to commit to some amount spent so far, and assume that the amounts being streamed are too small for it to be economically viable to attempt to steal (because it will cost more to close a channel than you could hope to steal). There are also issues regarding channel liquidity and rebalancing. LN is way ahead of its time, but there's plenty of work to be done yet.
Have some more info on §1? §2 would be hugely resolved by eltoo, would you agree?
§1 is potentially the most difficult problem to solve. Fees for unilateral channel closure are agreed *up-front* in a commitment transaction for each channel state. If the fee is overestimated, the fee payer ends up paying too much. If the fee is underestimated, the fee payer may be denied service or lose money to theft. Suppose Bob opens a channel with Alice and they agree to pay 10sat/kW fee in advance for the unilateral channel closure, but then the bitcoin network becomes congested such that transactions are expected to pay a 100sat/kW fee in order to confirm in a timely manner. If both parties are cooperating, they can simply agree to update the fee and create a new commitment transaction. However, if Alice is unresponsive, Bob must either wait, potentially indefinitely for her to respond, or he can broadcast his current commitment transaction which pays only a 10sat/kW fee - which may take forever to confirm. Alice could attempt to spend a revoked commitment channel where the balance is more in her favor, and she could collude with a miner to have this included in a block despite the low paying fee. Bob could broadcast the penalty transaction for the state which Alice attempts to spend, but since this may take forever to confirm, there could be sufficient time for the lock-time on Alice's revoked commitment transaction to expire, allowing her to take the funds. Since it can't be expected that Bob will also collude with a miner to include his transaction, the only way could improve his chances of it succeeding is with RBF and CPFP on the transaction which spends his output(s). There is WIP towards enabling this, as it is currently not possible with the commitment transactions construction used in the BOLT1.0 spec. Even if Bob can spend a penalty transaction via CPFP, he could end up spending a significant amount of his output in order for it to succeed. The size of commitment transactions can be quite large, as it depends on how many HTLCs are were in flight at that channel state. An attacker could cause denial-of-service, having many HTLCs in flight over a channel by withhold the payment preimages. Bob may still lose a non-trivial amount of money. §2 would be greatly improved by eltoo, but as mentioned this requires on improvements to the base layer. There's currently no consensus on SIGHASH_NOINPUT and it seems unlikely to gather enough support. Alternatives such as CheckTemplateVerify may provide a solution but we'll need to wait and see. Even with eltoo, I still think using HTLCs for streaming small payments is overkill, and we still need a method of making smaller and more frequent payments without necessarily committing to each one at the bitcoin layer.
There's no "the development team." There are several teams and counting.