Rusty Russell on Nostr: #cln #dev #someday Wallet "Intents" With anchor channels, lightning nodes were forced ...
#cln #dev #someday
Wallet "Intents"
With anchor channels, lightning nodes were forced to get smarter about tx construction. (Kind of funny, nobody really wanted to write a Bitcoin wallet, but here we all are). You have a deadline, user wants to spend as little as possible, you have to use CPFP to boost the commitment tx, and bring your own fees for any HTLC txs (which are now single input/output ANYONECANPAY|SINGLE).
I did the minimal things to get this to work, but it brings me back to the question of how these things *should* work. I don't think the primary interface for a wallet should be "spend these utxos to create this output" but "do this by this time, with this budget cap". The wallet should figure out how to do it.
For example: sources include onchain funds, splicable channels and even closing channels. What if the wallet code had a rough "cost" for each of these? Sinks include splicing in, onchain outputs (maybe to cold storage?) or new channels. And there are also specific txs you might want. It should combine them opportunistically (and later, pull them apart if priorities change).
There are several problems though. The first is complexity: this is not trivial to get all the cases correct, and all the combinations. The second is related: understandability and debugging is hard too: what did it do, what did it decide *not* to do, and was the result optimal? i.e. why?
But mainly, how to present this to the user? Or the plugins that they use to direct it? They need to know that funds are coming to them (especially since we low-ball fees for non-urgent things). Plugins will want to see PSBTs before they get signed, so they can do clever things (coinjoin, open new channels, combine in other ways).
The upside of all this is maximum efficiency, and a side-helping of more confusing transaction graphs. Both of which help everyone.
This is currently an idle thought: it's not going to reach the top of my TODO this year, for sure!
Wallet "Intents"
With anchor channels, lightning nodes were forced to get smarter about tx construction. (Kind of funny, nobody really wanted to write a Bitcoin wallet, but here we all are). You have a deadline, user wants to spend as little as possible, you have to use CPFP to boost the commitment tx, and bring your own fees for any HTLC txs (which are now single input/output ANYONECANPAY|SINGLE).
I did the minimal things to get this to work, but it brings me back to the question of how these things *should* work. I don't think the primary interface for a wallet should be "spend these utxos to create this output" but "do this by this time, with this budget cap". The wallet should figure out how to do it.
For example: sources include onchain funds, splicable channels and even closing channels. What if the wallet code had a rough "cost" for each of these? Sinks include splicing in, onchain outputs (maybe to cold storage?) or new channels. And there are also specific txs you might want. It should combine them opportunistically (and later, pull them apart if priorities change).
There are several problems though. The first is complexity: this is not trivial to get all the cases correct, and all the combinations. The second is related: understandability and debugging is hard too: what did it do, what did it decide *not* to do, and was the result optimal? i.e. why?
But mainly, how to present this to the user? Or the plugins that they use to direct it? They need to know that funds are coming to them (especially since we low-ball fees for non-urgent things). Plugins will want to see PSBTs before they get signed, so they can do clever things (coinjoin, open new channels, combine in other ways).
The upside of all this is maximum efficiency, and a side-helping of more confusing transaction graphs. Both of which help everyone.
This is currently an idle thought: it's not going to reach the top of my TODO this year, for sure!