Open ryanthegentry opened 2 days ago
I haven't really gone through the panic stack trace but this log might be the source of this behavior
2024-12-02 17:50:52.141 [ERR] CRTR: Payment 5b3734500a06f1326ce7520656cec97050c94143b732474a425ca4d7e3ac40b0 failed: traffic shaper failed to produce extra data: asset unit price ({1000000 2024-12-02 18:50:51 +0000 UTC} asset per BTC) too high to represent HTLC value of 11000 mSAT
Based on the above log, the mock oracle is configured to provide a price of 100sats per asset unit, and since the invoice we're trying to pay is 10sats, the asset cannot represent such small value
possible todos include:
possible todos include: Make the above error visible to the user
In this case we should fail back with a clear error message.
We can take the config above and craft an itest around it to protection against regressions here.
Fwiw, I reproduced the network except with Alice, Bob and Carol all having --taproot-assets.experimental.rfq.mockoracleassetsperbtc=100000000
in their config (100x the previous), and the same 10 sat payment worked like a charm as expected:
litd@alice:/$ litcli ln payinvoice --pay_req lnbcrt100n1pn5uq25pp5k5yld0m38hrmeukzpxgs5e5svy6eq2n20dtac5c95gn3ej6c0qcqdqqcqzzsxqyz5
vqsp5ypq7ekvcvzcs3zduu0g0zsc8ehctmxr8p78ey2cflw882gh03cfq9qxpqysgqmad4tk8hw7clmlx6ee2609gt07n80daw43dcek5s8rrn6e90y95kjvnh8fhjf3ycv
yqsjaan2yqltw3ec32y9s02ang8es56ty2j88qplzrrtx --asset_id f53f62c96150deef2a6c6c89c064d44e5c168a384853d8ccb8f2ec3cef094259 --rfq_pee
r_pubkey 03ff47f05bfb410e14160acdd32f811de9564977299f2ecbf3b28524d0935c65f0
Payment hash: b509f6bf713dc7bcf2c209910a66906135902a6a7b57dc5305a2271ccb587830
Description:
Amount (in satoshis): 10
Fee limit (in satoshis): 10
Destination: 0273cc02d5ae136ed3e2a185adfbe4ee79a7be981c52b9cb767a0cba1d26e51d3e
Confirm payment (yes/no): yes
Got quote for 10 asset units at 1000 msat/unit from peer 03ff47f05bfb410e14160acdd32f811de9564977299f2ecbf3b28524d0935c65f0 with SCID 17731376342856276633
+------------+--------------+--------------+--------------+-----+----------+-----------------+------------+
| HTLC_STATE | ATTEMPT_TIME | RESOLVE_TIME | RECEIVER_AMT | FEE | TIMELOCK | CHAN_OUT | ROUTE |
+------------+--------------+--------------+--------------+-----+----------+-----------------+------------+
| SUCCEEDED | 0.255 | 1.638 | 10 | 1 | 300 | 145135534931968 | bob->carol |
+------------+--------------+--------------+--------------+-----+----------+-----------------+------------+
Amount + fee: 10 + 1 sat
Payment hash: b509f6bf713dc7bcf2c209910a66906135902a6a7b57dc5305a2271ccb587830
Payment status: SUCCEEDED, preimage: 4e171e89dd5835525f35ef3e8bc8a978bd2a03219da17618fcc042ec0f72ae8b
Even a 1 sat payment worked! So will def guide edge node operators/issuers/price oracle devs when testing to set assetsperbtc > 100M, and to try to ensure 1 asset ~= 1 sat.
Yes I ran into this issue as well on Signet
ubuntu@signet:~$ litcli ln payinvoice --pay_req lntbs10510n1pn5udg7pp5yl3hw9c2m7amr0psp20gk4xf6v8k9m9e2pde6wqq7qavyhp3tgwsdp82pshjgr5dusyymrfde4jq4mpd3kx2apq24ek2uscqzpuxqzfvsp5zlx5zqx6cp75cts7hsgy0h8jmeqw6h36g3hwvsjngq93606qmvqq9p4gqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpqysgqxjr8np46thh0g8crq6jmwz46g6edajh4w43ywad5575fcy3kwfkps9dmsg5prk8svzh2m5rdhpszzlasutptv9aw3wg4tru4n9vcdasp35cr7e --asset_id f477e00819e4ea0ec87e38a74c808e5ec24fc07ec84f4a6e7f2f1436e7ebe664
Payment hash: 27e377170adfbbb1bc300a9e8b54c9d30f62ecb9505b9d3800f03ac25c315a1d
Description: Pay to Blink Wallet User
Amount (in satoshis): 1051
Fee limit (in satoshis): 52
Destination: 03bb03bb6e389355834c9fc7dfeb849dab17d9940d955f6dba0c27e84c88ca4ab8
Confirm payment (yes/no): yes
panic: runtime error: integer divide by zero
goroutine 1 [running]:
main.(*resultStreamWrapper).Recv(0xc0007ce3d8)
github.com/lightninglabs/lightning-terminal/cmd/litcli/ln.go:219 +0x2ee
github.com/lightningnetwork/lnd/cmd/commands.PrintLivePayment({0x21975c0, 0xc0003fed20}, {0x217a240, 0xc0007ce3d8}, {0x21c8640, 0xc0005df1b0}, 0x0)
github.com/lightningnetwork/lnd@v0.18.4-beta.rc1/cmd/commands/cmd_payments.go:711 +0xa3
github.com/lightningnetwork/lnd/cmd/commands.SendPaymentRequest(0xc00058e6e0, 0xc00058f600, {0x218b870, 0xc000171008}, {0x218b870, 0xc000171008}, 0xc00009ea30)
github.com/lightningnetwork/lnd@v0.18.4-beta.rc1/cmd/commands/cmd_payments.go:626 +0x97c
main.payInvoice(0xc00058e6e0)
github.com/lightninglabs/lightning-terminal/cmd/litcli/ln.go:461 +0x505
github.com/urfave/cli.HandleAction({0x19d1600?, 0x1f79958?}, 0xa?)
github.com/urfave/cli@v1.22.9/app.go:524 +0x50
github.com/urfave/cli.Command.Run({{0x1e0ad9d, 0xa}, {0x0, 0x0}, {0x0, 0x0, 0x0}, {0x1e571d7, 0x2d}, {0x0, ...}, ...}, ...)
github.com/urfave/cli@v1.22.9/command.go:173 +0x67c
github.com/urfave/cli.(*App).RunAsSubcommand(0xc00058cfc0, 0xc00058e420)
github.com/urfave/cli@v1.22.9/app.go:405 +0xddb
github.com/urfave/cli.Command.startApp({{0x1e01e9c, 0x2}, {0x0, 0x0}, {0x0, 0x0, 0x0}, {0x1e41b3c, 0x24}, {0x0, ...}, ...}, ...)
github.com/urfave/cli@v1.22.9/command.go:378 +0xb1e
github.com/urfave/cli.Command.Run({{0x1e01e9c, 0x2}, {0x0, 0x0}, {0x0, 0x0, 0x0}, {0x1e41b3c, 0x24}, {0x0, ...}, ...}, ...)
github.com/urfave/cli@v1.22.9/command.go:102 +0x7a8
github.com/urfave/cli.(*App).Run(0xc00058ce00, {0xc000050080, 0x8, 0x8})
github.com/urfave/cli@v1.22.9/app.go:277 +0xb1b
main.main()
github.com/lightninglabs/lightning-terminal/cmd/litcli/main.go:103 +0xbb6
Ah, so this is actually just in the litcli
code that displays the result, so litd
doesn't panic, only the CLI:
main.(*resultStreamWrapper).Recv(0xc0007ce3d8)
github.com/lightninglabs/lightning-terminal/cmd/litcli/ln.go:219
Background
I am testing single hop Taproot Assets LN payments in Polar. I have three litd v0.14.0-alpha.rc1 nodes (each backed by their own bitcoind v27.0 node) Alice, Bob, and Carol. Alice has minted 21M units of a Taproot Asset called USDTest with a decimal_display of 6, and opened a 1M asset channel to Bob (so Alice has 1M assets outbound liquidity). Bob has then opened a 1M sats channel to Carol, and is using the default edge node config
--taproot-assets.experimental.rfq.mockoracleassetsperbtc=1000000
. I am testing Alice trying to pay sats invoices generated by Carol, whether paying in Taproot Assets or in sats.Your environment
Alice's litd config:
Alice's tapcli getinfo output:
Bob's litd config:
Bob's tapcli getinfo output:
Steps to reproduce
1) Create the single hop Taproot Assets LN to BTC network architecture described above 2) Have Carol generate a 10 sats invoice (lnbcrt100n1pn5muhppp5tvmng5q2qmcnym882gr9dnkfwpgvjs2rkueywjjztjjd0cavgzcqdqqcqzzsxqyz5vqsp5xj837yyv53xzpf6mgqhlnsdj2hpazs88evmy6cs486cllsmd4k8s9qxpqysgqmajxgkxph2ny8gzfy5l80w256he50k2s6zsupyj320nh9ts2ul3y7ask3yeqsjnxhlqtx25kdc2z5a22d5g557mv5xf4cksw0nktemspml9vup) 3) Attempt to pay that invoice with the command
litcli ln payinvoice --pay_req lnbcrt100n1pn5muhppp5tvmng5q2qmcnym882gr9dnkfwpgvjs2rkueywjjztjjd0cavgzcqdqqcqzzsxqyz5vqsp5xj837yyv53xzpf6mgqhlnsdj2hpazs88evmy6cs486cllsmd4k8s9qxpqysgqmajxgkxph2ny8gzfy5l80w256he50k2s6zsupyj320nh9ts2ul3y7ask3yeqsjnxhlqtx25kdc2z5a22d5g557mv5xf4cksw0nktemspml9vup --asset_id 3da18be97ca3b399129be4242061bcde054082be0c1a36b8d2b7750a4a461919 --rfq_peer_pubkey 0370175e690645b4c47f462aa1f94aa08d79af1460c3e8f548b803b34b9c5603ef
Expected behavior
Given that this request is asking Alice to send 0.1 assets across her Taproot Assets channel, the
litcli ln payinvoice
command should fail gracefully with feedback that the amount is too small instead of panicking.Actual behavior
Alice receives the following CLI output:
Alice's logs show the following: