Every time we are involved in a specific solution we learn something new and are reminded how dynamic the LN space is. Bitcoin payments on their face are very simple; if they weren’t it wouldn’t be a viable monetary network. The beauty of bitcoin is that there are no issue with on-chain payments*. This of course comes at the cost of confirmation times and variable fees. All that follows then is the result of the ongoing effort to provide an instant finality payment network via LN.
The ever-improving UX standard of wallets is such that any 2 people can easily generate and pay an invoice by means of QR code. This is between 2 hot wallets and, as such, it is common and best practice to only have a small value of sats in your balance at any time – analogous to having £20 in your wallet. The problem is that to participate in LN you have to be connected to an LN node. This is true of bitcoin per se (i.e. you need to be connected to a bitcoin node to use bitcoin), but the scope of dishonesty and loss is greater in LN when using Someone Else’s Node. In terms of user numbers, most LN wallets use Someone Else’s (LN) Node.
In terms of payment success and ease, using some else’s well connected, always synchronised, and liquidity managed node is superior. In essence, in contrast to bitcoin-core-running-nodes, not all LN nodes are equal. But the fact of trusting the node runner not to rug-pull funds on the node goes against the general ethos of bitcoin. So self-custodial LN wallets have been developed, for example Blixt, Bluewallet, Phoenix, Mutiny, and others.
This time out, we saw quite a few instances of self custodial LN wallets causing issues at point of sale. This is something we’ve suspected in the course of running BTCPay Server invoice generation for online stores. Where we’ve seen unpaid invoices we have often considered them to be result of timeouts due to lack of balance. But having witnessed difficulties with self custodial wallets, these are increasingly a contributor to PoS difficulties.
The first problem is synchronisation. When going to pay, the customer opens their wallet and has to wait. Next, it’s the issue of actually running an LN node. Self custodial LN wallets either connect to your own LND node (e.g. Bluewallet), which might not be well connected to other nodes, or the phone becomes an LN node itself and the software has some way of opening channels on the fly. If not anticipating these issues ahead of time it will result in issues. We suspect people open nodes with counterparties they often buy from, for example Bitrefill or The Bitcoin Company. The issue being that these nodes are managed to ensure inbound capacity to receive payments, rather than for routing purposes. The centrality of the end user’s LN node can be poor and this can cause routing and payment issues.
This is a valuable reminder that there are no solutions and only trade-offs. We tend to rank the importance of ease of use and serviceability over all else given the competition is very easy to use – card payments and bank transfers don’t fail. Yes, you are open to censorship, but the average person is not yet censored. This is in contrast to some who favour self custodial everything. We understand the ethos completely, and in an ideal world the average person would be both interested in, and capable of, pursuing such an endpoint. But unfortunately they are not, and even many who try do not always understand the admin and forethought that comes along with it. Hopefully there is an increased level of knowledge about what is required to use self custodial LN wallets and we’re sure UX will continue to improve. But it does serve to highlight why custodial solutions like Wallet of Satoshi will likely continue to be important. Here again, knowledge of the trade-offs and appropriate usage is also required.
What we’ll be doing about it is helping clients improve their payment success rate by improving their nodes’ connectivity in respect of self custodial wallets and by gathering information about failed payments by means of customer follow up.
*failing extreme coordinated and costly edge case bad faith action by a majority of hashrate providers
