Multi rfq send itest #1097

GeorgeTsagk · 2025-06-23T14:07:59Z

Description

Enhances the multi-rfq itest to cover multi-rfq send functionality. In the following topology

	  /---[sats]--> Erin --[assets]--\
	 /                                \
	/                                  \

 Charlie  -----[sats]-->  Dave  --[assets]---->Fabia

	\                                  /
	 \                                /
	  \---[sats]--> Yara --[assets]--/

we now also get Fabia to pay Charlie back, with amounts that exceed the capacity of each individual channel. We also use a hold invoice to validate that multiple HTLCs were added in different channels.

Related PRs (in order of merge sequence):

ZZiigguurraatt · 2025-06-28T15:22:21Z

Seems like you should update

https://github.com/GeorgeTsagk/lightning-terminal/blob/c7dbe80f1b6463bb01fe2f94f72cf52b6b6ab9de/itest/litd_custom_channels_test.go#L2973-L2977

to mention the send test, possibly renaming the function name?

ZZiigguurraatt · 2025-06-28T15:30:24Z

In the following topology

	  /---[sats]--> Erin --[assets]--\
	 /                                \
	/                                  \

 Charlie  -----[sats]-->  Dave  --[assets]---->Fabia

	\                                  /
	 \                                /
	  \---[sats]--> Yara --[assets]--/

Do we see any value in adding tests where Charlie has more or less channels than Fabia? Like this route seems a bit too simple because both sender and receiver kind of need the same sharding.

I'm also wondering if we should test where Charlie-Dave have asset channels and not sats channels.

I don't think this test should be removed, but I think there should be some more complex network that tests more than what this test can do in another function.

GeorgeTsagk · 2025-07-02T10:55:33Z

Linter / unit tests fail because of this
https://github.com/lightninglabs/lightning-terminal/actions/runs/16022889778/job/45203816341?pr=1097#step:5:317

accounts/sql_migration_test.go:340:19: undefined: sqldb.MigrationTxOptions (typecheck)

which is not related to this PR, the itests should normally run & pass

GeorgeTsagk · 2025-07-04T11:41:48Z

The last commit adds a new node to the topology, which always rejects quotes, causing a reliable RFQ negotiation failure this way

The tests pass, but they do now expose some potential bug in the RFQ negotiation code where we hang until timeout if the rfq negotiation is not successful.

guggero

LGTM pending a couple of nits.

guggero · 2025-07-07T07:56:47Z

itest/assets_test.go

@@ -1733,8 +1737,8 @@ func payInvoiceWithAssets(t *testing.T, payer, rfqPeer *HarnessNode,
 		acceptedQuote := quoteMsg.GetAcceptedSellOrder()
 		require.NotNil(t, acceptedQuote)

-		peerPubKey := acceptedQuote.Peer
-		require.Equal(t, peerPubKey, rfqPeer.PubKeyStr)
+		// peerPubKey := acceptedQuote.Peer


nit: commented out code.

guggero · 2025-07-07T07:59:05Z

itest/assets_test.go

@@ -264,6 +307,19 @@ func createTestMultiRFQAssetNetwork(t *harnessTest, net *NetworkHarness,
 	require.NoError(t.t, err)
 	t.Logf("Funded channel between Yara and Fabia: %v", fundRespYF)

+	// We fund the Yara->Fabia channel.


nit: comment mismatch.

guggero · 2025-07-07T08:00:50Z

itest/litd_custom_channels_test.go

+		"--taproot-assets.allow-public-uni-proof-courier",
+		"--taproot-assets.universe.public-access=rw",
+		"--taproot-assets.universe.sync-all-assets",
+		"--taproot-assets.universerpccourier.skipinitdelay",
+		"--taproot-assets.universerpccourier.backoffresetwait=1s",
+		"--taproot-assets.universerpccourier.numtries=5",
+		"--taproot-assets.universerpccourier.initialbackoff=300ms",
+		"--taproot-assets.universerpccourier.maxbackoff=600ms",
+		"--taproot-assets.universerpccourier.skipinitdelay",
+		"--taproot-assets.universerpccourier.backoffresetwait=100ms",
+		"--taproot-assets.universerpccourier.initialbackoff=300ms",
+		"--taproot-assets.universerpccourier.maxbackoff=600ms",
+		"--taproot-assets.custodianproofretrievaldelay=500ms",


nit: can use append(litdArgsTemplateNoOracle, []string{ instead of duplicating all these values (since they look identical at first glance).

ZZiigguurraatt · 2025-07-07T14:16:06Z

itest/litd_custom_channels_test.go

+
+	// Let's make another round-trip involving multi-rfq functionality.
+	// Let's have Fabia receive another large payment and send it back
+	// again, this time with a greater amount.


and you are also using a group key too instead of an asset id? does/should this test ensure that it shards and multiple asset ID are used in the group key or is it not trying to check for that?

we do more extensive tests around assetID/groupkey in diff itests (mostly the liquidity edge cases) here I'm just switching things up a bit just as an extra sanity check

lightninglabs-deploy · 2025-07-14T14:50:49Z

@ffranr: review reminder
@GeorgeTsagk, remember to re-request review from reviewers when ready

ZZiigguurraatt · 2025-07-18T12:54:02Z

go.mod

@@ -247,3 +247,7 @@ replace google.golang.org/protobuf => github.com/lightninglabs/protobuf-go-hex-d
 // it is a replace in the tapd repository, it doesn't get propagated here
 // automatically, so we need to add it manually.
 replace github.com/golang-migrate/migrate/v4 => github.com/lightninglabs/migrate/v4 v4.18.2-9023d66a-fork-pr-2
+


please remove these lines now that lightningnetwork/lnd#9980 has been merged

ffranr

Need to remove the replace in go.mod, and some other outstanding comments, otherwise good to go.

ZZiigguurraatt · 2025-07-21T13:43:06Z

Need to remove the replace in go.mod, and some other outstanding comments, otherwise good to go.

FYI: I made a branch where I rebased and then updated all the packages. Not sure if you want to use it or re-do it another way.

https://github.com/ZZiigguurraatt/taproot-assets/tree/group-key-addr-part-2%2Bmulti-rfq-send

ZZiigguurraatt · 2025-07-21T15:05:03Z

Need to remove the replace in go.mod, and some other outstanding comments, otherwise good to go.

FYI: I made a branch where I rebased and then updated all the packages. Not sure if you want to use it or re-do it another way.

https://github.com/ZZiigguurraatt/taproot-assets/tree/group-key-addr-part-2%2Bmulti-rfq-send

sorry, got this PR mixed up with the other one.

guggero · 2025-07-23T06:25:25Z

@GeorgeTsagk can you please rebase this to the tapd-main-branch branch? We can't bump tapd on master branch yet, as we're not ready to release what will become tapd v0.7.0 yet (in case we need to do an emergency minor release of litd).

ZZiigguurraatt · 2025-07-24T14:16:02Z

@GeorgeTsagk can you please rebase this to the tapd-main-branch branch? We can't bump tapd on master branch yet, as we're not ready to release what will become tapd v0.7.0 yet (in case we need to do an emergency minor release of litd).

do we want to prio lightninglabs/loop#968 now so that this can be done more cleanly?

GeorgeTsagk self-assigned this Jun 23, 2025

GeorgeTsagk force-pushed the multi-rfq-send-itest branch 2 times, most recently from 6165322 to c7dbe80 Compare June 27, 2025 12:10

GeorgeTsagk force-pushed the multi-rfq-send-itest branch 2 times, most recently from 1e79938 to 533a39f Compare July 2, 2025 10:39

GeorgeTsagk requested review from guggero and ffranr July 2, 2025 10:39

guggero approved these changes Jul 7, 2025

View reviewed changes

ZZiigguurraatt reviewed Jul 7, 2025

View reviewed changes

ZZiigguurraatt mentioned this pull request Jul 8, 2025

[bug]: can't find route through a channel I know about and I can reach its channel peer lightningnetwork/lnd#10056

Open

ZZiigguurraatt mentioned this pull request Jul 15, 2025

[bug]: OpenChannel randomly fails with peer XXX is not online lightningnetwork/lnd#10078

Open

ZZiigguurraatt reviewed Jul 18, 2025

View reviewed changes

ffranr reviewed Jul 21, 2025

View reviewed changes

GeorgeTsagk force-pushed the multi-rfq-send-itest branch from 33aa187 to b60e3e4 Compare July 22, 2025 13:22

GeorgeTsagk added 5 commits July 22, 2025 15:33

build: bump tapd, loop

3c01648

itest: allow setting empty peer pubkey on tapd SendPayment

f509718

itest: enhance multi-rfq itest with sending

4fbe62c

make+itest: pin multi-rfq Yara node to v0.15.0-alpha

079ba9a

itest: add George node to multi-rfq topology

7e35182

GeorgeTsagk force-pushed the multi-rfq-send-itest branch from b60e3e4 to 7e35182 Compare July 22, 2025 13:35

GeorgeTsagk requested a review from ffranr July 22, 2025 13:35

ffranr approved these changes Jul 22, 2025

View reviewed changes

ffranr added the no-changelog This PR is does not require a release notes entry label Jul 22, 2025

Multi rfq send itest #1097

Are you sure you want to change the base?

Multi rfq send itest #1097

Uh oh!

Conversation

GeorgeTsagk commented Jun 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

ZZiigguurraatt commented Jun 28, 2025

Uh oh!

ZZiigguurraatt commented Jun 28, 2025

Uh oh!

GeorgeTsagk commented Jul 2, 2025

Uh oh!

GeorgeTsagk commented Jul 4, 2025

Uh oh!

guggero left a comment

Choose a reason for hiding this comment

Uh oh!

guggero Jul 7, 2025

Choose a reason for hiding this comment

Uh oh!

guggero Jul 7, 2025

Choose a reason for hiding this comment

Uh oh!

guggero Jul 7, 2025

Choose a reason for hiding this comment

Uh oh!

ZZiigguurraatt Jul 7, 2025

Choose a reason for hiding this comment

Uh oh!

GeorgeTsagk Jul 22, 2025

Choose a reason for hiding this comment

Uh oh!

lightninglabs-deploy commented Jul 14, 2025

Uh oh!

ZZiigguurraatt Jul 18, 2025

Choose a reason for hiding this comment

Uh oh!

ffranr left a comment

Choose a reason for hiding this comment

Uh oh!

ZZiigguurraatt commented Jul 21, 2025

Uh oh!

ZZiigguurraatt commented Jul 21, 2025

Uh oh!

guggero commented Jul 23, 2025

Uh oh!

ZZiigguurraatt commented Jul 24, 2025

Uh oh!

Uh oh!

GeorgeTsagk commented Jun 23, 2025 •

edited

Loading