[Lightning-dev] Consideration for user-facing interface

ZmnSCPxj ZmnSCPxj at protonmail.com
Thu May 25 03:04:25 UTC 2017


Good morning everyone,

I would like to present my consideration for how the user-facing interface would be like, for a "mainstream"(-ish?) LN software.

Please inform me, if there are particular abstraction leakages that would suffer in my consideration.

A Lightning-enabled wallet would have three tabs: On-chain, In-transit, and On-Lightning. The tabs would show how much Bitcoin is in each of those states, and some separate part of the interface would include the total funds of all three tabs.

The On-chain view would show the coins (abstractions of UTXO's) owned on-chain. Coins would be grouped according to PKH that unlocks that UTXO (for "mainstream", I think, a "coin" would be better term, than UTXO), especially since it would be good practice to claim all coins in a PKH in a transaction. In addition, the coin would also show an estimate of the fee required to add that UTXO as input to a transaction (basically, the bytes needed for the input spending the UTXO underneath the coin, times the fee rate done by some hidden backend fee rate estimation service/algorithm), and if the fee estimate is greater than some fraction of the coin it will be grayed (i.e. more trouble to spend the coin than hodl it).

In the On-chain view it would be possible to send on-chain, generate a receive address, and also to transfer funds from on-chain to on-Lightning. Possibly, it might also be useful to have some way to select multiple coins and "consolidate" them into a single larger coin, for example to reduce future fees.

In the In-transit tab, contains a list of funds that are "in-transit", i.e. in unconfirmed transactions. These include funding and commitment transactions. In addition, channels whose counterparty is currently offline would be included in this list (as it would not be Lightning-spendable with the counterparty offline) and the user may choose to unilaterally close to force it On-Chain; since a unilateral close has a timeout it would also be included here as "in-transit". Unconfirmed transactions may be "sped up" by either CPFP and/or RBF (possibly without actually using those terms for "mainstream"; instead the wallet simply includes a "speed up" command and perhaps use RBF-enabled on all transactions).

In the On-Lightning tab would be almost empty other than the ability to send On-Lightning, generate a LN invoice, and to transfer funds from on-Lightning to On-Chain. I hesitate to put channels in, as I do not know of some good abstraction for them (at least UTXO=coin, would be explainable as saying that Bitcoin coins have their own denominations). Of course, since counterparties in channels may go offline, perhaps I need to show them after all...

(the problem with showing channels is that, if you enable "hub mode" (localfeatures bit 0/1) in your LN node, individual channel values will shift and change as other network participants use your node as routes, but in my opinion, for the health of LN, it should be default to have "hub mode" enabled)

The software would keep track of which LN nodes the user usually pays On-Lightning. When moving funds from On-Chain to On-Lightning, the software will prioritize making channels to nodes the user usually pays to, to help reduce future routing fees. In addition, the software will also perform randomized channel open (randomly select some peer to open channels to) to hopefully reduce LN centralization (or some other algorithm to improve LN mesh connectivity).

When paying On-Lightning, and unable to find a route to the payee, the software could offer to create a direct channel (from On-chain funds) to allow payment; this has the necessary caveat that payment may be delayed due to on-chain confirmation requirements.

For On-Lightning fees, the user specifies some maximum percentage of total routing fees in some setting. If the software can find and use a route below this maximum percentage, then it simply performs the payment (for example, if the user specifies a maximum of 3% routing fees, and the software finds a route through two nodes each asking 1% fee (for a total of 2.01%) then the payment is attempted via that route). However, if routes below this setting cannot be found or fail, the software would offer to increase this maximum percentage temporarily for this payment, to allow the user to consider if higher fees can be justified for the service payment.

---

It seems to me, for now, that HTLC preimages sent by update_fulfill_htlc can serve as receipts: when the payer receives this either on-chain or on-Lightning, then it definitively knows that the payee has received the money. So, it seems to me that this preimage can be given by the payer to the payee as proof-of-payment, and thereby trigger, for example, the \delivery of goods from the payee. Is my understanding correct? If so, it seems to me that a list of such receipts should also be archived by the software, with the user able to selectively burn some receipts (for example, to burn receipts from donating to wikileaks).

Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20170524/b79a285a/attachment-0001.html>


More information about the Lightning-dev mailing list