Prepare for custom channels (lnd v0.18.4-beta) #848
Conversation
guggero
force-pushed
the
update-to-lnd-18-4
branch
from
8ab9d4c
to
5c64ab5
Compare
guggero
force-pushed
the
update-to-lnd-18-4
branch
from
5c64ab5
to
35e6aea
Compare
|
Similar to lightninglabs/loop#828, I bumped to We will want to wait with merging this until the full dependency chain above is resolved. But once |
|
Need to add #861. |
|
@jamaljsr I tagged you for review on this with the intention of asking you to run a full manual test run of this version within Polar (all the tests you've run previously). |
|
@guggero Thanks for the clarification. I wasn't sure how I should test this or if it was ready. I will try it out in Polar by early next week at the latest, hopefully sooner. Excited to see this functionality getting mainlined 🙌 |
guggero
force-pushed
the
update-to-lnd-18-4
branch
from
35e6aea
to
ef8f8cf
Compare
guggero
force-pushed
the
update-to-lnd-18-4
branch
2 times, most recently
from
23d6696
to
1335e4b
Compare
|
This PR now contains all the recently merged PRs of the |
guggero
force-pushed
the
update-to-lnd-18-4
branch
3 times, most recently
from
3d30a93
to
9476c03
Compare
There was a problem hiding this comment.
tACK LGTM 🔥 🚀
I tested the following scenarios in Polar using this network structure with all litd nodes except for erin which is Core Lightning v24.08.1.
alice --[asset]-> bob --[sats]-> carol --[asset]-> dave
|
[sats]
|
v
erin (core-ln)
- fund asset channel using full asset balance after mint
- fund asset channel using partial asset balance after mint
- fund asset channel using full asset balance after mint + onchain send
- fund asset channel using partial asset balance after mint + onchain send
- fund asset channel using full asset balance from onchain receive
- fund asset channel using partial asset balance from onchain receive
- fund asset channel with
push_sat=5000 - create asset invoice on dave, pay with asset on alice (multi-hop)
- create asset invoice on bob, pay with asset on alice (direct peer)
- create asset invoice on alice, pay with asset on bob (direct peer, opposite direction)
- create asset invoice on alice, pay with asset on dave (multi-hop, opposite direction)
- create asset invoice on dave, pay with sats on bob (sats -> asset)
- create sats invoice on bob, pay with asset on dave (asset -> sats)
- create asset invoice on alice, pay with sats on erin (cln sats -> asset)
- create sats invoice on erin, pay with asset on alice (asset -> cln sats)
- create sats invoice on bob, pay with sats on alice (direct peer, sats -> sats)
- create sats invoice on dave, pay with sats on alice (multi-hop, sats -> sats)
- send asset keysend payment from alice to bob
- send asset keysend payment from alice to carol
Note: I was using commit 35e6aea. I see there have been more pushes since I started testing. Let me know if you'd like another round of testing using the final commits before merging.
guggero
force-pushed
the
update-to-lnd-18-4
branch
from
9476c03
to
cf2458e
Compare
|
Thanks so much for the explanation. Now it totally makes sense. I just have one follow-up question, for my own information, in the cases when sending smaller asset payments. If I only send 500 PUSD, how are the routing fees distributed? I assume the equivalent sats value is too small to be represented as an asset unit. Are the fees then added to the sats amount of the HTLC? |
|
There is a certain amount of "underpayment" allowed when the conversion from asset to sats is off due to the precision. Currently 1 asset unit per HTLC (and up to 16 asset units per invoice, due to the MPP default max shard amount of 16) is allowed. That precision loss is basically paid by the edge node. |
|
Got it! Thanks again for the explanations. Very informative 🙏 |
guggero
force-pushed
the
update-to-lnd-18-4
branch
3 times, most recently
from
9d2c79d
to
9c10445
Compare
guggero
force-pushed
the
update-to-lnd-18-4
branch
3 times, most recently
from
f308629
to
bc786e9
Compare
guggero
force-pushed
the
update-to-lnd-18-4
branch
from
bc786e9
to
31a6ad5
Compare
This commit represents the main integration between lnd running in integrated mode and tapd providing auxiliary components for custom channels.
This change will speed up integration tests by not waiting a full 5 seconds before re-trying the connection to lnd if it fails the first time.
Add the `priceoraclerpc`, `rfqrpc`, and the `tapchannelrpc` JSON callbacks to the litclient's `Registrations` array. This allows the litclient to use the rpc functions contained in these JSON callbacks.
Add testCustomChannelsMultiInput to verify multi-input channel funding. In this test Charlie mints an asset, transfers it to Dave in two separate txs. Dave then uses both asset UTXOs to fund a channel with Charlie that is bigger than the value of either UTXO.
This commit adds a fully configurable RPC oracle that can serve asset rates that differ for buy and sell. We then add a test that shows and asserts proper asset conversion to satoshis and back.
With this commit we sporadically assert in our itests that the outgoing HTLCs for a payment and the incoming HTLCs of an invoice show the custom channel data JSON with the actual asset amounts.
This commit removes the default value of 1 for `sat_per_vbyte` that's being passed to `litd` rpc endpoint `fundchannel`. `litd` handles this now perfectly on its own, and adding logic here only adds to the confusion.
This commit adds an integration test for the MinRelayFee check. The test ensures that transactions with fees below the minimum relay fee are rejected.
guggero
force-pushed
the
update-to-lnd-18-4
branch
from
d53e5ea
to
8754bcb
Compare
This is the mother of all PRs for the custom channel saga. Merging this PR will be the final step for bringing custom channels to a non-experimental version of litd. There are many dependencies (see list/graph below), so it will remain in draft for a bit.
Most of the code in these PRs have already been reviewed on the
0-19-stagingbranch and have just been squashed down into easy-to-review pieces.The following list is an ordered list of dependencies that need to be resolved before this PR can be merged (cc @dstadulis):
lndclient v0.18.4-0that points to release branch with stable commitslndclient v0.18.4-0(and with it also bumping thelndversion), take out of draftlndclient v0.18.4-0(and with it also bumping thelndversion), take out of draftlndclient v0.18.4-0(and with it also bumping thelndversion), take out of draftlnd v0.18.4-betato be tagged (at least an RC tag) [release]: Cherry Pick Commits for LND v0.18.4 Release lightningnetwork/lnd#9173lnd-18-4to track lndv0.18.4-betarelease lndclient#194 point to the tagged version oflndlndclient v0.18.4-1lndclient v0.18.4-1lndclient v0.18.4-1lndclient v0.18.4-1loop,pool,tapd)NOTE: This PR includes all recent changes to
litd's0-19-stagingbranch, including the new liquidity tests from #842. There haven't been any other in-flight PRs to the staging branch when writing this.