liquidity ad implementation #4637
Closed
Conversation
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
Import the wires from spec. Here we go!
When we get a node announcement out, we can now pull out its offer characteristic
Correctly mark whether or not the TLV's are the same/different, given two node announcements
If there's a rate-card for liquidity, we don't know about it until after startup (the plugin *should* call us at init to tell us what their current rates are)
Changelog-Added: JSON-RPC: new RPC `setleaserates`, for passing in the rates to advertise for a channel lease (option_will_fund)
Note that we use the names from the spec. Changelog-Added: EXPERIMENTAL JSON-RPC: `listnodes` now includes the `lease_rates`, if available
A couple of the fields for liquidity_ads are u16
If received lease rates are empty (all zeroes), turn them off
Implement support for liquidity ads in `funder` plugin. We set the command line options for the leases, as well as sending the updated ads to lightningd (who then passes them through to gossipd)
Make sure everything updates/flows through as expected.
Will re-use these for the psbt weight payment calc later
convenience, mostly
When we accept a bid to create a channel lease, we send back a signature committing to our max channel lease amounts.
When a request comes through, we forward it over to the funder who uses the currently set policy to figure out how to handle it. Includes small update to the policy engine which decides whether or not to fund a request. Changelog-Added: Plugins: `openchannel2` hook now includes optional fields for a channel lease request
Changelog-Added: EXPERIMENTAL-DUAL-FUND: JSON-RPC: openchannel_init now takes a `requested_amt`, which is an amount to request from peer
Changelog-Added: JSON-RPC: `fundchannel` now takes optional `request_amt` parameter
Asks HSMD for signed lease termsheet, fills in the details to the accept_channel2 TLV
we'll use it again here shortly
Undocumented RPC call for asking a peer what their rates are
option_will_fund changes the to_remote/to_local commitment tx outputs by altering the CSV lock for leased channels. We need to grind/scan for these outputs now, provided the defaults don't work.
Adds new tables to database, backfills, basically copies the fee_rates state machine for channeld.
Useful for parsing a passed in feerate before calling lightningd with it, e.g. when you need to know what the feerate is for a fundpsbt before calling fundpsbt Changelog-Added: JSON-RPC: new command `parsefeerate` which takes a feerate string and returns the calculated perkw/perkb
Makes it a bit more flexible.
If the channel is under lease, the lessor's (accepter, really) funds have a CSV lock that reflects the length of the remainder of the lease.
Channel leases modify the CSV height that an output is eligible for being spent at, persist this to the database
If an output's CSV lock hasn't been surpassed yet, don't try to include it in a transaction
Typically we forget a channel if 2016 blocks have passed and the funding transaction hasn't been mined yet, however we SHOULD NOT forget these channels if we've got funds in them!
If the channel is leased and our peer is too far behind, fail the channel.
By default, we won't close a channel that we leased to a peer. You can override this with the `force_lease_closed` flag. Changelog-Added: JSON-RPC: close now has parameter to force close a leased channel (option_will_fund)
We need to update the peer wrt our blockheight on reconnect
We're gonna need them
We need to know what the lease we're expecting is. To do this we pass around the hex encoded portion of the wire format. We can use this passed in expected lease rates to confirm that the peer is, in fact, using the same rates as what we have currently. Changelog-Added: JSON-RPC: fundchannel, multifundchannel, and openchannel_init now accept a 'compact_lease' for any requested funds
We need to parse the feerate string, so we can figure out what our weight fee will be for a leased channel, so we go get the feerate and use that to calculate what our expected lease fee will be for the requested amount.
If there's no plugin currently in place, we simply won't return any funding at all, in which case we'd expect them to handle however they want. (our implementation would fail the open, as we only accept opens that have at least as much as we've requested provided)
Make it easier to figure out what the inputs were to check_balances on two failure cases
We need the 'actual' accepter's funding for the reserve calculations, which includes the lease fee that the opener is paying them, so we calculate it before doing all that jazz. However, we MUST send the actual "on paper" (e.g. without lease fee) amount to the peer in accept_channel2, so we stash the original amount and send it.
with channel leases, we use the open_tlv data after a round of talking to the peer (which clears out the tmpctx). It'll get cleaned up when this peer opens/fails.
Check that channel leases work as expected for unilateral closes and cheats!
Since we now use 'compact_lease' to gate an open (if the rates have changed, we fail), we no longer need to rely on query rates for figuring things out, so we make it dev-only. Changelog-Changed: JSON-API: queryrates is now developer only
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Work in progress; implements lightning/bolts#878
Tests are broken.