For years, we've been hearing about how Lightning will solve all of Bitcoin Core's problems...

I have to admit, seeing some of the recent posts on the Bitcoin subreddit has led me to see some of the more optimistic viewpoints about the Lightning network: that Bitcoin could be moved at very low (virtually non-existent) costs through lightning "channels" that are setup.

It also made me believe that the propaganda was true: perhaps the developers behind Bitcoin Cash (BCH) were indeed "scared" that mining fees would be eliminated (as a lot of the support was based from Chinese companies, which have a heavy stake in mining hardware and existing mining operations)...which is why they were so hesitant to adopt the technical "advancements" being promised by core.

My mind has been changed.

I saw a great post today by an OpenBazaar Developer that has explained the deficiencies of the Lightning network better than any explanation I've seen of the benefits...and it makes me think that perhaps Bitcoin Cash's method to scale (simply increase the blocksize) is better than Bitcoin Core (SegWit, Lightning, etc. etc.).

Simplicity is almost always better...but these devs have to know better than I do, right? Well, that's what I thought until I read an actual use case of how Lightning will set the network backwards and cause problems.

Full text reply from this thread ("Will OpenBazaar Implement Lightning Network Features?") follows:

1.) Vendors need to remain online 24/7 to receive orders.

One of primary pieces of feedback from OpenBazaar 1.0 was that vendors did not like having to run a server on their home computer 24/7 to make sales. That requirement was a remant of the original Dark Market design and it was one of the primary things we wanted to change for OpenBazaar 2.0. For 2.0 we spent an enormous amount of time re-architecting OpenBazaar (and moved to IPFS) specifically to allow vendors to receive orders while they are offline. With the LN vendors need to remain online to provide a hash to all would-be purchasers to kick off the lightning payment. If the vendor is not online, the payment cannot be made. This would represent a significant regression in the user experience and would bring back the primary user complaint from OpenBazaar 1.0.

2.) Vendors cannot receive LN payments without a third party liquidity provider.

If a vendor opens OpenBazaar, opens a payment channel, lists some items, then receives an order, the buyer cannot pay for the order over LN since the vendor's counterparty does not have any funds in his side of the channel to send to the vendor. The only way for the vendor to receive an incoming payment is to have buyers open a direct channel (innefficient and unacceptably expensive) or open a channel with an intitutional liquidity provider who agrees (probably for a fee) to deposit money in the vendor's channel to facilitate incoming payments. This is not a great UX and introduces some significant friction into the app (not to mention no such insitutional liquidity providers currently exist). Moreover it's difficult to calculate exactly how much money the liquidity provider should deposit in the channel. Is $1,000 enough? Hard to say. If buyers try to pay more than $1,000 worth of orders before the vendor can spend the coins out of the channel (presumably to an exchange) then the those additional payments cannot be made. This creates a weird UX where the vendor has to continually try to juggle the amount of funds available in the incoming side of the channel to ensure that there is enough liquidity to facilitate payments.

3.) Vendors will need third party "watchers".

Since OpenBazaar users have expressed distain for a requirement to a full node to use the software, they would be left with the rather ugly solution to having to hire a third party "watcher" (which currently do not exist) to protect them from fraud.

4.) Lightning currently does not do multisig.

Escrowed payments are a necessary prerequisit for any decentralized marketplace to function. In theory lightning payments could use 2 out of 3 hashes in the HTLC, but no software currently supports this functionality and doing so introduces dramatically more complexity on top of an already dramatically complex protocol. And it would require the moderators to remain online at all times else escrowed payments could not be made.

5.) It's not clear that LN payments will be 100% reliable.

Whether a payment can find a route depends on how many people use LN and how they use it. If the routing paths simply do not exist or if they exist but lack the needed capacity than payments can not be made. For an app like OpenBazaar to gain any kind of sizable user base, the app (including the payment layer) needs to be 100% reliable. If this is not the case it will make the app feel broken and discourage many people from using it. At this point in time we do not know if 100% reliability in payment routing is likely or not.

In my opinion at present time using just about any coin other than Bitcoin removes all of the above frictions and provides a much better user experience. Unless the benefits of lightning (relative to the alternatives) outweigh these costs outlined above, or they find a way to remedy the issues defined above, it doesn't make much sense to implement LN in OpenBazaar.

---

TLDR; If you can't use Lightning Network for PAYMENTS on a marketplace...then what the hell can it be used for?

This post by the OB Developers was enlightening for me. Maybe it will be for you, too.