Have you tried using the Lightning Network for yourself? How about Nano? I've tried many of the LN wallets that are out there, and they all have the same fundamental issues that cannot easily be abstracted away. Nano is faster, simpler, and cheaper (0 fees) than the Bitcoin Lightning Network.
LN isn't a solution for one off peer-to-peer payments. You first have to open a channel on the first layer (which costs fees and time), so LN primarily helps in cases of repeat transactions, not one off peer-to-peer transactions. You also have to pre-commit some amount of BTC AND all channels routing to your destination must have enough BTC to route your payment.
- Requires opening & closing channels on the first layer (costs fees + time)
- The first layer currently doesn't have enough TPS to onboard even a PayPal level of users that want to use LN
- Must be online at all times
- For core nodes, **private keys** must be held online
- You must pre-commit BTC capacity to fund channels
- Some of your channel capacity has to be reserved to close the channel
- The cost to close a channel can fluctuate, potentially trapping your BTC
- If a channel is force closed, you have to wait for your money to be returned
- The seed is not enough to recover LN funds, you have to backup current state
- LN routing is not a solved problem; one third of LN payment attempts fail: https://blog.dshr.org/2020/01/bitcoins-lightning-network.html
- Optimal LN usage will be through centralized hubs that route payments for you (who will probably require KYC)
- LN requires some level of trust (hence Watchtowers)
- LN trends towards centralized, well-connected nodes
See page 49 of the Lightning Network whitepaper: https://lightning.network/lightning-network-paper.pdf
Here are some video comparisons of the two:
tekdemonPlatinum | QC: BTC 246, CC 98, BCH 81 | r/Android 8 months ago
So you’ve pointed out a lot of the weaknesses of LN. But it’s rather misleading to pretend like there aren’t already solutions to many of these and solutions coming for most of the rest. Square will easily be able to abstract away 95% of this.
Autopilot randomly selects nodes to connect to, and you should always wait for confirmation to be safe. It doesn't solve the reserved balances issue either (for channel closing).
1s/byte is still a fee, and you can't guarantee the first layer will always accept 1s/b fees for opening/closing. Fees are an additional UX issue for users (choosing the right fee, leftover dust, etc)
"Generally" is not always. Those edge cases are going to bite average users hard at times. The safest case is to be online or to have a watchtower (more hassle, more fees).
**I don't have to deal with any of that hassle, and I get a better experience.**
>Autopilot randomly selects nodes to connect to, and you should always wait for confirmation to be safe. It doesn't solve the reserved balances issue either (for channel closing).
What issue do you see with randomly selecting nodes? Also, it doesn't need to randomly select, that's a design choice that has been made and it can be changed if required.
>1s/byte is still a fee, and you can't guarantee the first layer will always accept 1s/b fees for opening/closing. Fees are an additional UX issue for users (choosing the right fee, leftover dust, etc)
1s/byte is currently approximately 1 cent. It's still a fee but that 1 cent allows me to keep a channel that can be spent from and paid to for as long as I choose to keep a channel open, most of mine have been open for more than 10 months now.
I've never had a channel funding transaction take more than a day, If that changes in the future it can be dealt with then - you can always bump the fee if it's really required.
>"Generally" is not always. Those edge cases are going to bite average users hard at times. The safest case is to be online or to have a watchtower (more hassle, more fees).
Watchtowers cost penny shavings in fees, again not a real problem as far as I'm concerned.
>I don't have to deal with any of that hassle, and I get a better experience.
An order of magnitude more people use Bitcoin than Nano, I would argue that Bitcoin has a better experience by virtue of the fact that the average Bitcoin user finds it much easier to find someone to transact with than the average Nano user.
That doesn't seem to be changing either, the average daily transaction volume on Nano has been on a slow decline for more than 2 years now.
There's no need to trust him, the project mentioned in the article is open source, so we can verify for ourselves whether to trust it or not. Frankly, I think it's great to see them funding developers to help expand the LN ecosystem.
Yeah but it is their SDK, and their API, and their entire Dev kit. The fact that it is open source means the SDK is open source, but it doesn't change the fact that there is still a need to trust him. Why would I connect my services to somebody else's API who is known to not fit in with the censorship-resistant crowd? Facebook's dev kit for their crypto Libra is open source, but that doesn't mean Libra should be trusted. Politics or not, it never plays out well when big tech gets involved with these types of technologies.
Are you sure about that, then why did they have to base an API off of the pre-existing Rust lightning project? Also, where is Square's repo to verify it isn't connecting or pinging to anything? I can't find it on their list yet: [https://github.com/square](https://github.com/square?)
Given I wrote or reviewed almost every line of it, yea, I’m sure. The work we’re basing things on was linked in the blog post - https://github.com/rust-bitcoin/rust-lightning .We’re super independent from the rest of square and have a mandate to build up bitcoin so that square can go use it more broadly in the future, even if we literally compete with square in the short term (which arguably we did by funding BTCPayServer).