VLS + CLN: `psbt: Psbt(NonStandardSighashType(39))` on `ValidateCommitmentTx`
Summary
Sometimes the VLS signer refuses to handle a validate_commitment_tx
message, due to an invalid sighash type. This commitment transaction comes from CLN, on testnet, with a recently opened channel.
If I understand correctly CLN (v0.11.2) is not setting a sighash type, and this is just random data (the type changes from time to time). Ideally we'd set a valid sighash type in CLN, but we need to first confirm that that's the issue at hand here.
VLS commit:
Steps to reproduce
- Start CLN (v0.11.2) with VLS on testnet
- Open a channel with some other peer on the network
- Attempt to pay an invoice (or anything else that may trigger an HTLC to be added)
Relevant logs and/or screenshots
[2023-02-17T11:14:48Z TRACE gl_client::signer] Handling message ValidateCommitmentTx(ValidateCommitmentTx { tx: 02000000014f6e7574dc918a24f138eec7418cc5e6a752cc10cee97176223e38145e479f4b0000000000253ae98002e903000000000000220020ca4983a02dd28ce744079642c393b35fb0a35914c2d72e9b92c3e2d1c675311cd42b1e00000000002200202fd4ee2aad90e10519d8744a18b1e59380d8b25dad1bf92cb2f08da6cc83ebb83e370d20, psbt: 70736274ff01008902000000014f6e7574dc918a24f138eec7418cc5e6a752cc10cee97176223e38145e479f4b0000000000253ae98002e903000000000000220020ca4983a02dd28ce744079642c393b35fb0a35914c2d72e9b92c3e2d1c675311cd42b1e00000000002200202fd4ee2aad90e10519d8744a18b1e59380d8b25dad1bf92cb2f08da6cc83ebb83e370d200001012ba0301e0000000000220020f29a7b5ac6d1cdfa74bb8cb4f97d746e1ffa4a0a16ab00d4f0be56bd37b412822202031397cdc944659af0c5d99abe05f5a673d09a38acb22aa72d8a3fa25966615eb84069c10ab2cc0d8cdef5931e4d520e236aafccd7fc0cd56c94da3e46233403ec4764d1902b2ffd0d1d1204c894561a595c3477aaf8ef90713434ed45ee070c902701030401000000010547522102e56249dd4964ae3d98447d1aabccc6f7cc9fb05cccd40c8fbddb365d80e3174a21031397cdc944659af0c5d99abe05f5a673d09a38acb22aa72d8a3fa25966615eb852ae220602e56249dd4964ae3d98447d1aabccc6f7cc9fb05cccd40c8fbddb365d80e3174a08fbf8f8c6000000002206031397cdc944659af0c5d99abe05f5a673d09a38acb22aa72d8a3fa25966615eb808faed09eb000000000001018576a914196e06525a8d9f9d9a0ee584c4bc054515f510928763ac6721025991dea12fc09ee45dd74b30dde93484e48b89afa8e9c9170041a284a018c0a87c820120876475527c210294594c4f106632b90a073c527d4a4824e4f5cd477a5b24b0fa2c727f5e4ba77b52ae67a9142b137e19ef0ff053478f265eb2961acae51838d788ac68680001014b632102f83941d8480e341b6444be1e65d6fbcc717f1e81ff7c763a986ccd1bacf877016756b2752102b6668e6b6612b84c66b687c3390fcd3b2365ab8806010a72838aad26b1681b0a68ac00, htlcs: [Htlc { side: 0, amount: 1001510, payment_hash: Sha256([91, 58, 41, 48, 165, 233, 169, 247, 242, 86, 36, 110, 229, 191, 86, 177, 15, 170, 9, 67,
67, 98, 182, 78, 67, 241, 228, 75, 200, 46, 155, 185]), ctlv_expiry: 2420601 }], commitment_number: 1, feerate: 253, signature: BitcoinSignature { signature: [71, 236, 3, 52, 35, 70, 62, 218, 148, 108, 213, 12, 252, 215, 204, 175, 106, 35, 14, 82, 77, 30, 147, 245, 222, 140, 13, 204, 178, 10, 193, 105, 39, 144, 12, 7, 238, 69, 237, 52, 52, 113, 144, 239, 248, 170, 119, 52, 92, 89, 26, 86, 148, 200, 4, 18, 29, 13, 253, 47, 43, 144, 209, 100], sighash: 1 }, htlc_signatures:
[BitcoinSignature { signature: [45, 147, 83, 204, 226, 89, 102, 200, 148, 227, 142, 4, 76, 124, 31, 63, 141, 130, 100, 189, 122, 111, 16, 252, 81, 145, 67, 112, 126, 224, 151, 13, 127, 31, 192, 252, 44, 164, 26, 192, 139, 48, 225, 158, 137, 26, 118, 184, 241, 67, 14, 165, 130, 75, 107, 46, 191, 9, 247, 114, 56, 167, 229, 99], sighash: 1 }] })
[2023-02-17T11:14:48Z INFO vls_protocol_signer::handler] Restore node 02f767adf4bad49f729785deda23a42c30e12965d8337b11667d403e74e5b4e66e
[2023-02-17T11:14:48Z INFO lightning_signer::node] Restore node 02f767adf4bad49f729785deda23a42c30e12965d8337b11667d403e74e5b4e66e on testnet
[2023-02-17T11:14:48Z INFO lightning_signer::node] Restore channel 0225ff2ae6a3d9722b625072503c2f64f6eddb78d739379d2ee55a16b3b0ed0a170700000000000000
[2023-02-17T11:14:48Z INFO lightning_signer::node] Restore channel 02eadbd9e7557375161df8b646776a547c5cbc2e95b3071ec81553f8ec2cea3b8c0500000000000000
[2023-02-17T11:14:48Z INFO lightning_signer::node] Restore channel 038863cf8ab91046230f561cd5b386cbff8309fa02e3f0c3ed161a3aeb64a643b90600000000000000
thread '<unnamed>' panicked at 'psbt: Psbt(NonStandardSighashType(39))', /home/cdecker/dev/greenlight/public/vls/vls-protocol-signer/src/handler.rs:911:22
VLS Version Info
The version is the latest version compatible with v0.11.2, I am about to migrate to v22.11 too, so if this issue is fixed on a later version of VLS I'm happy to ignore this issue :-)
In a vls
tree:
git describe v0.1.0-5-679-g1fcaf0f--tags --long --always --match='v*.*'
Possible fixes
- Add the PSBT sighash flags to the ignore list for the permissive mode
- Adjust CLN to set the sighash flags correctly (old version)