XCM delivery fee breaks XCM compatibility

[xlc]

A failed transfer: https://karura.subscan.io/xcm_message/kusama-024c52268887c3fb756eeea47242a7d2d831b6ba

Since the new Kusama runtime upgrade, which includes #1234, KSM transfer between parachains stops working.

This is due to the XCM execution on Kusama unable to charge deliver fee from holding register and therefore refuse to send DMP to dest chain.

This also highlights a main issue with the current deliver fee mechanism. It is infeasible to query and calculate the delivery fee pure from onchain runtime. It is a tx version breaking change to ask user to specify an extra delivery fee parameter. It is not possible to enable jit_withdraw mode in this particular case. It just doesn't work.

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/polkadot-digest-26-jan-2024/5848/1

[albertov19]

Similar problem here -> https://kusama.subscan.io/extrinsic/21573927-7

[acatangiu]

@xlc do you have a chopstix test or similar to use to test out ideas for quick fixes?

I believe something like this 371d5b0 could get us running again until we come up with a comprehensive solution for:

This also highlights a main issue with the current deliver fee mechanism. It is infeasible to query and calculate the delivery fee pure from onchain runtime.

[acatangiu]

Also, does no one have these scenarios running on testnets?

#1234 is live on Rococo relay and System Chains since 3-4 months now - not cool getting burned directly on Kusama 😢

[xlc]

To reproduce this with Chopsticks

To run the networks
KARURA_BLOCK_NUMBER=6136909 KUSAMA_BLOCK_NUMBER=21594465 BIFROST_BLOCK_NUMBER=5895485 npx @acala-network/chopsticks@latest xcm --relaychain kusama --parachain karura --parachain bifrost

Open Karura and send the extrinsic:
https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A8000#/rpc

submit author.submitExtrinsic with data:
0x95028400842745b99b8042d28a7c677d9469332bfc24aa5266c7ec57c43c7af125a0c16c016ed23bfa0338e2c971e6e9c1e375b56c6791de705fee18e43d2f0d7c1e06f864546e9b62179b9691e364cb9aa39773f1b8b090980cbd66a2b4e551b70cb0c28da4008981003600008200743ba40b000000000000000000000003010200451f0100842745b99b8042d28a7c677d9469332bfc24aa5266c7ec57c43c7af125a0c16c00

Submit it and wait for few minutes to produce blocks. Check terminal logs for output.

Check the new block produced on Kusama: https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A8002#/explorer

If the issue is fixed, check the block on Bifrost: https://polkadot.js.org/apps/?rpc=ws%3A%2F%2F127.0.0.1%3A8001#/explorer

To test the fix or print XCM logs, we need to do wasm override for Kusama:
copy the kusama config: https://github.com/AcalaNetwork/chopsticks/blob/master/configs/kusama.yml
specify wasm-override point to the new Kusama runtime
repeat from step 1 but use --relaychain path/to/kuama.yml

[xlc]

I can create something similar to https://github.com/xlc/chopsticks-ksm-xcm tomorrow. but it should be trivial enough to modify it to test for this bug

[itsbirdo]

Linked issue: #3075

[adaOctopus]

Same issue for me. Bridging KSM to KAR seems fine in the explorer, but KSM funds never arrived to the KAR wallet.
https://kusama.subscan.io/extrinsic/21602766-2
Any ideas when this is fixed and if funds have been lost?

[albertov19]

FYI - I've created two scripts to calculate the worst-case scenario for Kusama -> Parachain KSM transfers and from AssetHub -> Parachain Asset Transfers:

Kusama -> https://github.com/albertov19/xcmTools/blob/main/calculateKusamaDeliveryFees.ts
AssetHub -> https://github.com/albertov19/xcmTools/blob/main/calculateAHXcmDeliveryFees.ts

These scripts assume the worst-case scenario by applying U128::MAX to the variable input of the elements that result in the "longest" XCM possible. This check should be done in the origin chain (either Kusama or AssetHub) by dApps, and add this value to the tx fee of paymentInfo endpoint.

[rageruun]

Tokens stuck in parachain bridge when transmitted from the Kusama network to the Moonriver (xcKSM).

[acatangiu]

update:

fix is merged to patch-release branch: #3085 and released to crates.io: https://crates.io/crates/staging-xcm-executor/4.0.1

another fix is also being backported #3113 and 4.0.2 needs to be published to crates.io

next, we'll have to include it in Polkadot & Kusama runtimes and do a patch release there

[rageruun]

thanks вт, 30 янв. 2024 г. в 14:22, Adrian Catangiu ***@***.***>:

…

update: fix is merged to patch-release branch: #3085 <#3085> and released to crates.io: https://crates.io/crates/staging-xcm-executor/4.0.1 another fix is also being backported #3113 <#3113> and 4.0.2 needs to be published to crates.io next, we'll have to include it in Polkadot & Kusama runtimes and do a patch release there — Reply to this email directly, view it on GitHub <#3070 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWYFUHTIER5QJB4ACQ2VPP3YRDQXHAVCNFSM6AAAAABCLU37ACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJWG4ZDONZSGM> . You are receiving this because you commented.Message ID: ***@***.***>

[Hawkarhf92]

Please someone help, I sent some KSM 5 days ago but still not received, from kusama network to Sora mainnet, but xcm transfer not created, here is my extrinsic hash, (0x78540d5b0b3831468c7c4a70ef5a81bccb3c7cb96e44ad81e39c96e73a9ebcff ) please help ,