Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Channel Capacity MAX button prevent change dust #157

Open
seth586 opened this issue Jan 29, 2019 · 6 comments
Open

Channel Capacity MAX button prevent change dust #157

seth586 opened this issue Jan 29, 2019 · 6 comments

Comments

@seth586
Copy link

seth586 commented Jan 29, 2019

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.

@wbobeirne
Copy link
Member

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?

@seth586
Copy link
Author

seth586 commented Jan 29, 2019

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
Copy link
Author

seth586 commented Jan 30, 2019

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.

@wbobeirne
Copy link
Member

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?

@jamaljsr
Copy link
Collaborator

@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.

@githorray
Copy link

Probably easier to implement once LND has coin control features.

lightningnetwork/lnd#2976

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants