joule-extension icon indicating copy to clipboard operation
joule-extension copied to clipboard

Channel Capacity MAX button prevent change dust

Open seth586 opened this issue 5 years ago • 6 comments

It would be nice to commit an entire UTXO to a channel, to prevent change dust being created. I would suggest a MAX button to commit all funds to funding a channel.

seth586 avatar Jan 29 '19 17:01 seth586

Interesting idea. What would you imagine it look like if you have multiple UTXOs to choose from? Should it combine them, or have you choose between them?

wbobeirne avatar Jan 29 '19 17:01 wbobeirne

For the sake of UI, you don't even need a button, just let the user type in 'max' into the amount field.

Using 'max' would be useful for committing the rest of your funds. Opening channels with the intention of not using all on-chain funds doesn't require a coin control scheme.

If you do want to go the coin control route, then instead of asking users to type in amounts, list suggested amounts based on utxos, and a 'custom' button to type in an amount that would result in a change output.

Looking long term the survivability of bitcoin requires high fees on chain. Dust will one day become uneconomical to spend, resulting in lost funds.

seth586 avatar Jan 29 '19 21:01 seth586

coin_control_joule

Excuse my terrible mspaint skills, but coin control does a few things:

  1. It promotes responsible use of the blockchain space. Many small UTXOs became unspendable during the 2017 hype cycle, only now can they be economically consolidated. Currently, coins get split over and over again as channels are closed and reopened with user designated amounts.

  2. It educates the user without ever having them read a topic on change addresses and transaction sizes. As the user selects more UTXOs, the miner fee goes up. The user intuitively learns that it is not wise to create more coins.

seth586 avatar Jan 30 '19 01:01 seth586

Thanks for the mockup (way better than I could pull off in MS Paint), it definitely makes your idea clear! I like this idea conceptually, but I think it'll require a little more massaging on the design side to make it more understandable to users. I'll circle back to this one later.

It also helps that LND has an API endpoint for getting your UTXOs, so this looks very doable. The only thing I'm not sure of is how smart LND is about not creating dust given the right amount of satoshis. If I have 3 UTXOs, [1000, 1500, 2000] and I specify a channel with a capacity of 2500, will it know to use the 1000 &1500 UTXOs? Or will it try to use 1000 & 2000 or 1500 & 2000?

wbobeirne avatar Jan 30 '19 01:01 wbobeirne

@wbobeirne
If I have 3 UTXOs, [1000, 1500, 2000] and I specify a channel with a capacity of 2500, will it know to use the 1000 &1500 UTXOs? Or will it try to use 1000 & 2000 or 1500 & 2000?

Just adding my 2 cents here. I've done a fair bit of investigating into how the UTXOs are chosen when creating an on-chain transaction. It turns out that LND always chooses UTXOs starting from highest value to smallest until it reaches the target amount you would like to spend (ref1, ref2). The selection logic also takes into account the fee based on the serialized size of the transaction. So a higher specified fee (sats/B) can push it to choose more outputs than if a lower fee was given. The implementation for opening a channel is far more complex than just sending an onchain tx since it has to communicate with the peer to create the multi-sig.

There's currently no API endpoint that would allow third-party apps like Joule to instruct LND to use outputs X & Y when opening the channel or sending an onchain tx. So it doesn't look like it would currently be possible to offer coin selection in Joule.

jamaljsr avatar Feb 26 '19 20:02 jamaljsr

Probably easier to implement once LND has coin control features.

https://github.com/lightningnetwork/lnd/issues/2976

githorray avatar Aug 25 '19 02:08 githorray