-
Notifications
You must be signed in to change notification settings - Fork 267
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
17 changed files
with
361 additions
and
98 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,73 @@ | ||
# Liquidity Ads | ||
|
||
## Tasks | ||
|
||
- triple-check the codecs and add commments to the spec PR accordingly | ||
- for phoenix, start with a version where we don't modify the commit tx to add a CLTV | ||
- only need to store information about all leases paid somewhere for reporting | ||
- add tests | ||
- modify commit txs (`to_local` and `to_remote`) and store lease info somewhere | ||
- implement the `lightning-kmp` side | ||
- when leasing liquidity: | ||
- ensure we don't raise our relay fees above what was negotiated while the lease is active | ||
- disallow mutual close and force-close commands during the lease | ||
- use a dedicated bitcoin wallet, on which we never lock utxos (abstract it away at the `BitcoinCoreClient` level) | ||
- but for Phoenix we will keep using the existing wallet | ||
- when buying liquidity: | ||
- when doing an RBF, must pay for the lease `fundingWeight` at the new feerate (add test and make sure the seller checks those fees) | ||
- verify our peer doesn't raise their relay fees above what was negotiated: if they do, send a `warning` and log it | ||
- ignore remote `shutdown` messages? Send a `warning` and log? | ||
- when we receive `tx_init_rbf`: | ||
- if they previously asked for liquidity and aren't asking for it anymore, remove our contribution | ||
- otherwise they would get liquidity for free by making an RBF attempt right after the funding attempt | ||
- when we splice: | ||
- if the lease is still active, make sure it carries over to future commitments | ||
- if the lease is inactive, remove CLTV from commitments? | ||
- lease renewal mechanism: | ||
- unnecessary, it's just a splice that uses the `request_funds` tlv? | ||
|
||
## Spec feedback | ||
|
||
- restore base routing fee field | ||
- specify RBF behavior | ||
- HTLC output timelocks? | ||
- should the liquidity ads proportional fee in `node_announcement` be a per-block value? | ||
|
||
## Philosophical comments | ||
|
||
When buying a liquidity ads for a given `requested_amount`, what exactly are we buying? | ||
|
||
1. The `requested_amount` of inbound liquidity to be used *at least once* before the lease expires | ||
2. The `requested_amount` of inbound liquidity *and* any liquidity on the seller side for the duration of the lease | ||
|
||
Since we're introducing a CLTV expiry on the seller's output, we are effectively buying option 2. | ||
The seller cannot get any of their funds back without the buyer's cooperation because of that CLTV. | ||
But that is actually much harder to price than option 1, because a buyer could use the following trick: | ||
|
||
1. Alice buys 10k sats of liquidity from Bob for 1 year | ||
2. Alice splices-in 10BTC | ||
3. Alice sends 10BTC through that channel | ||
4. She paid for 10k of liquidity, but ends up with 10BTC that Bob cannot reclaim for a year! | ||
|
||
How could Alice correctly price her liquidity to take that into account? | ||
|
||
Another similar scenario: | ||
|
||
1. Alice buys 1BTC of liquidity from Bob for 1 week | ||
2. Alice then buys 10k sats of liquidity from Bob for 1 year | ||
|
||
Bob now has slightly more than 1BTC of liquidity stuck in a 1-year CLTV, but Alice only paid for 1 week. | ||
This could arguably be fixed by not allowing paying for a new lease while an existing lease is active, but that would be missing out on low-feerate opportunites... | ||
Or we'd need complex logic on Bob's side to decide whether or not to accept the new lease. | ||
|
||
If we think we're buying option 1, once the `requested_amount` has been sent from Bob to Alice, Bob should be free to reclaim any liquidity they have on their side. | ||
This could be done by allowing splice-outs, but that isn't sufficient, because if Alice simply rejects the splice-out, Bob is still stuck with a CLTV on his output. | ||
So we'd need to explicitly `stfu` the channel once the leased amount has been transferred and remove the CLTV from the commitment transactions. | ||
That requires some non-trivial logic when multiple leases overlap, but it's doable. | ||
But if Alice refuses to perform the CLTV removal and Bob has a lot of funds on their side, they're still fucked. | ||
|
||
We could in theory fix that by splitting the seller's amount into two outputs: the leased amount and the rest. | ||
But it may create edge cases when the leased output gets below dust? | ||
Or is that perfectly deterministic and easy to handle? | ||
It's easier to handle with 0-fee commit txs. | ||
It's an annoying change though, it requires a lot of code changes (to handle force-close, revocation, etc). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.