Let users set on-chain fees for autopilot in settings

[otech47]

Exploring this a bit to see whether I should take it on.. I'm imagining a slider something like the one in Lightning Joule:

But there's some functional complexity there ^ with the "auto" and "slow" labels that may not be necessary. A simpler form could me a 1 sat minimum but the maximum would still need to be dynamically calculated from the fastest next block fee estimate I think. I don't think an arbitrary max would be a good idea.

Thoughts?

[otech47]

Much needed feature by the way! 👍 Would love to see this in there

[tanx]

@otech47 thanks for the feedback. We've discussed doing a slider that allow setting sat/byte but have decided to go with a high/medium/low prio setting in the payment ui. See: https://github.com/lightninglabs/lightning-app/issues/1296

Definitely open to a sat/byte slider for future iterations if we get feedback from users that they'd like more control. Thoughts @leegordo?

[bolatovumar]

@tanx if fee estimation api is goo then having high/medium/low toggle is fine I find. However, many wallets have subpar fee estimation and often even the "low" setting fees are too high. You are using LND's fee estimation (right?) which seems to be better than the average.

[otech47]

@otech47 thanks for the feedback. We've discussed doing a slider that allow setting sat/byte but have decided to go with a high/medium/low prio setting in the payment ui. See: #1296

Definitely open to a sat/byte slider for future iterations if we get feedback from users that they'd like more control. Thoughts @leegordo?

Ok yeah I like the simplicity with that approach. I personally would like the ability to set 1 sat/byte so maybe the lowest toggle should be fixed to that, and medium/high can be estimated?

[bolatovumar]

@otech47 if 1 sat/byte is fixed and the user picks this option you could end up with a transaction that doesn't clear for a long time (or never) if there is a period of high demand for block space (in the next bull run or whatever).

[otech47]

@otech47 if 1 sat/byte is fixed and the user picks this option you could end up with a transaction that doesn't clear for a long time (or never) if there is a period of high demand for block space (in the next bull run or whatever).

I agree this is possible, but could be acceptable for the near future. I've been using 1 sat/byte and have never waited more than a day maximum, it's almost always a matter of hours. But I suppose we would want to anticipate some level of congestion in the next 12-18 months...

The Low setting definitely shouldn't be the default and maybe ~ 3-5 sats/byte would be more appropriate, just want to avoid the subpar fee estimation you mentioned. Ideally a replace-by-fee mechanism could be triggered after X hours or something in the background...?

I built a script that analyzes recent blocks for low fee transactions and at this moment, it's showing 11% (2432 / 21175) of transactions in the last 10 blocks had a fee rate of < 4 sats/byte

Maybe LND fee estimation is good enough though I haven't looked through that code

[tanx]

@otech47 if 1 sat/byte is fixed and the user picks this option you could end up with a transaction that doesn't clear for a long time (or never) if there is a period of high demand for block space (in the next bull run or whatever).

I agree this is possible, but could be acceptable for the near future. I've been using 1 sat/byte and have never waited more than a day maximum, it's almost always a matter of hours. But I suppose we would want to anticipate some level of congestion in the next 12-18 months...

That's a good point. I'm assuming we could add RBF in the tx details screen to mitigate that @Roasbeef? I like the idea of having a lower bound option for a final wallet sweeping tx when users likely don't really care when their tx is confirmed.

[bolatovumar]

@tanx i guess you could always have a fixed 1 sat/byte option and then "slow/medium/fast" options using the fee estimation API. This might be too complex from the UX perspective though.

[leegordo]

Yep me understand what the slider does?

On Fri, Aug 23, 2019 at 4:53 AM Tankred Hase notifications@github.com wrote:

@otech47 https://github.com/otech47 thanks for the feedback. We've discussed doing a slider that allow setting sat/byte but have decided to go with a high/medium/low prio setting in the payment ui. See: #1296 https://github.com/lightninglabs/lightning-app/issues/1296

Definitely open to a sat/byte slider for future iterations if we get feedback from users that they'd like more control. Thoughts @leegordo https://github.com/leegordo?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lightninglabs/lightning-app/issues/1298?email_source=notifications&email_token=ABBEP3FXVQTZGG6K4I23KMDQF7FUNA5CNFSM4INYGOL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD477YZI#issuecomment-524287077, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBEP3BRSY2PLGMZ3RRT3H3QF7FUNANCNFSM4INYGOLQ .

[otech47]

Yep me understand what the slider does?

@leegordo see: https://www.loom.com/share/26e93303d0bd4297a09b2caee9d6317c

[leegordo]

Got it! Thank you.

On Fri, Aug 23, 2019 at 9:44 AM Oscar Lafarga notifications@github.com wrote:

Yep me understand what the slider does?

@leegordo https://github.com/leegordo see: https://www.loom.com/share/26e93303d0bd4297a09b2caee9d6317c

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lightninglabs/lightning-app/issues/1298?email_source=notifications&email_token=ABBEP3GHJPWCIRRAXACGWO3QGAHYXA5CNFSM4INYGOL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5AXPNY#issuecomment-524384183, or mute the thread https://github.com/notifications/unsubscribe-auth/ABBEP3ETRPM2X72V77UHCUTQGAHYXANCNFSM4INYGOLQ .

[Roasbeef]

I'm assuming we could add RBF in the tx details screen to mitigate that @Roasbeef?

Yep! We already have both RBF and CPFP implemented internally within lnd, so it can be surfaced on the UI level once the time comes. We expose this as a generic BumpFee RPC, which'll choose between RBF and CPFP depending on the situation.