Stacks Transactions being rejected - Arkadiko, ALEX + Gamma

[pete-watters]

We are having some issues signing certain transactions in Leather Wallet. leather-io/extension#5115 . It seems like this is an issue with the ledger-stacks app as it is also causing problems when we try with Xverse.

Is this an issue that has been fixed and will be released soon? #157 ?

The problem is happening on Ledger nano S plus (firmware v1.1.1), And Ledger Nano X, with the latest firmware

The message we get back is:

{returnCode: 27012, errorMessage: 'Data is invalid : Unexpected data type’}

The problem can be produced using Arkadiko finance:

• Go to app.arkadiko.finance
• Sign in with Leather extension and Ledger device connected
• Go to Borrow
• Click any of the three options, for example xBTC, click the borrow button.
• Input amount of xBTC to collateralize
• mint a minimum of 500 USDA
• Click continue
• Click open vault
• Leather popup appears, click confirm
• We get {returnCode: 27012, errorMessage: 'Data is invalid : Unexpected data type’}

Users are also having this same issue when visiting Gamma Stacks NFT marketplace and trying to use Ledger. The Bitcoin ledger app is working but the Stacks app has this same error.

🔗 zboto Link

[neithanmo]

Thanks, @pete-watters there are many changes in #158 and #156 might solve those issues. it is possible to test them in a real device using the app/pkg/[email protected] installers

[neithanmo]

The problem is happening on Ledger nano S plus (firmware v1.1.1), And Ledger Nano X, with the latest firmware

Do you know if ledger Nanos also failed? Would it be possible to share the data being sent to the device? it would facilitate finding the issue

[pete-watters]

Thanks @neithanmo . I will test with a Nano S to see if that also fails. I can gather the data being sent also to help find the problem.

[pete-watters]

@neithanmo I tested just now and it is also failing using a Nano S. The easiest way to replicate it is to try and generate a signature on Stacking DAO.

1. Go to https://app.stackingdao.com/signer?pool=SP4SZE494VC2YC5JYG7AYFQ44F5Q4PYV7DVMDPBG.stacking-pool-v1
2. Authenticate with Leather Wallet
3. Click on either of the "Save Commit Signature" buttons and sign the message

The payload we are sending is:

[neithanmo]

This issue would not be fixed by any of the latest changes that will soon be merged.
it is likely that the number of nested values in that structured message is triggering a recursion limit in the app, to avoid consuming the stack that is very limited on nanos/s2/x or an unexpected data type in the message domain or while traversing the msg values.
there is no way to get the serialized data being send to the ledger? I can not tell with certainty that this is the case. i will take a look at the link and see if I can extract some data to use also in our testing suite

[neithanmo]

i do not see any save signature button

[pete-watters]

i do not see any save signature button

Thanks @neithanmo .

This issue isn't actually a problem in Leather Wallet itself. It occurs when trying to authorise transactions via Leather.

So if you:

• Sign in to a ledger with Leather wallet
• Go to https://app.stackingdao.com/signer?pool=SP4SZE494VC2YC5JYG7AYFQ44F5Q4PYV7DVMDPBG.stacking-pool-v1
• Authenticate with Leather Wallet
• Click on either of the "Save Commit Signature" buttons and sign the message

On Stacking Dao you should see a screen like this where you can replicate the error:

In the meantime I will try and get the serialised data in case it helps. Thanks!

[neithanmo]

Thanks @pete-watters. Is there any update on the structured_message being sent to the ledger?
maybe the serialized data? this would help a lot. but looking at the JSON payload you shared, the app checks the domain, and errors, if there are more/less than 3 fields(name, version, and chain_id), represented as a clarity tuple but it does not verify their values, later it recursively reads the rest of the message checking only that the clarity values are correct:

    pub fn verify(input: &'a [u8]) -> Result<(), ParserError> {
        let rem = Self::parse_prefix(input)?;
        // parse domain
        let (msg, _) = Domain::from_bytes(rem)?;

        // validate msg, but here we can limit the complexity
        // of the msg we can parse as the device has limited resources.
        //let's evaluate if a recursion limit of MAX_DEPTH is good for
        // general purposed structured data
        Self::validate(msg)?;

        Ok(())
    }

we have a recursion limit of MAX_DEPTH, used in case of nested values in the message. However looking at the payload image you share, I do not see complex data structures there that might trigger this limit

[pete-watters]

Hi @neithanmo,

Apologies for the delay, here is some sample data we are passing to app.sign_structured_msg

• stx_derivation_path: m/44'/5757'/0'/0/0
• domain: 0c0000000308636861696e2d69640100000000000000000000000000000001046e616d650d0000000c706f782d342d7369676e65720776657273696f6e0d00000005312e302e30
• payload: 0c0000000607617574682d696401000000000000000000000000000ca5640a6d61782d616d6f756e7401000000000000003635c9acdd09faf00006706572696f64010000000000000000000000000000000108706f782d616464720c000000020968617368627974657302000000142fffa9a09bb7fa7dced44834d77ee81c49c5f0cc0776657273696f6e0200000001040c7265776172642d6379636c65010000000000000000000000000000005905746f7069630d0000000a6167672d636f6d6d6974

Hopefully that helps? If not let me know and I can try and gather more information

[neithanmo]

Hi @neithanmo,

Apologies for the delay, here is some sample data we are passing to app.sign_structured_msg

* `stx_derivation_path`: `m/44'/5757'/0'/0/0 `

* `domain`: `0c0000000308636861696e2d69640100000000000000000000000000000001046e616d650d0000000c706f782d342d7369676e65720776657273696f6e0d00000005312e302e30`

* `payload`: `0c0000000607617574682d696401000000000000000000000000000ca5640a6d61782d616d6f756e7401000000000000003635c9acdd09faf00006706572696f64010000000000000000000000000000000108706f782d616464720c000000020968617368627974657302000000142fffa9a09bb7fa7dced44834d77ee81c49c5f0cc0776657273696f6e0200000001040c7265776172642d6379636c65010000000000000000000000000000005905746f7069630d0000000a6167672d636f6d6d6974 `

Hopefully that helps? If not let me know and I can try and gather more information

Thank You @pete-watters, That data is what we need. I will put it in our tests suite internally for easy debugging of this bug, hopefully, it would be about adjusting some types/value limits and not due to device limitations. I will keep you posted

[pete-watters]

Wow that's great news and thanks for the quick response. I will be slow to reply next week but if you need more assistance contact the team on here leather-io/extension#5115. Thanks again!

[neithanmo]

@pete-watters
after a quick test using the data you provided, I found no issues with it, the app handles it correctly. I was even running inside our device emulator with no errors.
That being said, is this the data causing the "Invalid Data" error?
Bellow the device UI showing part of the message domain and the payload/msg hash:

[pete-watters]

Hey @neithanmo ,

Thanks again for the help here, I am still investigating on our side. Its good if the data passes your emulator however on our side with an actual connected device no action is triggered so I don't see anything on the physical device.

We just receive the invalid payload error back.

When we send app. sign_structured_msg with the payload I gave above, Ledger rejects it with:

errorMessage: "Data is invalid : Unexpected data type"
returnCode: 27012

I gathered some information from another approach, where it fails when trying to create a new vault on Arkadiko. In that case we use app.sign and pass the following payload:

0000000001040025a6b5c2c50a2abbff700b87c8dfe29bda77523b0000000000000003000000000000e41800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003020000000101021625a6b5c2c50a2abbff700b87c8dfe29bda77523b16dbd1c48f77bf2f9506a3d79117fc1c7eda3b89100f577261707065642d426974636f696e0f777261707065642d626974636f696e05000000000015e3070216982f3ec112a5f5928a5c96a914bd733793b896a51f61726b6164696b6f2d7661756c74732d6f7065726174696f6e732d76312d320a6f70656e2d7661756c740000000b0616982f3ec112a5f5928a5c96a914bd733793b896a51b61726b6164696b6f2d7661756c74732d746f6b656e732d76312d310616982f3ec112a5f5928a5c96a914bd733793b896a51961726b6164696b6f2d7661756c74732d646174612d76312d310616982f3ec112a5f5928a5c96a914bd733793b896a51b61726b6164696b6f2d7661756c74732d736f727465642d76312d310616982f3ec112a5f5928a5c96a914bd733793b896a52061726b6164696b6f2d7661756c74732d706f6f6c2d6163746976652d76312d310616982f3ec112a5f5928a5c96a914bd733793b896a51c61726b6164696b6f2d7661756c74732d68656c706572732d76312d310616982f3ec112a5f5928a5c96a914bd733793b896a51461726b6164696b6f2d6f7261636c652d76322d330616dbd1c48f77bf2f9506a3d79117fc1c7eda3b89100f577261707065642d426974636f696e010000000000000000000000000015e307010000000000000000000000001ddca7400a0516c9a03720732a3148129a121f58d2ba37f6c649450100000000000000000000000000000000

That also fails and is rejected by the Ledger device with:

errorMessage: "Data is invalid : Authorization type not supported"
returnCode: 27012

In both above cases I am using a Ledger Nano X

[neithanmo]

I gathered some information from another approach, where it fails when trying to create a new vault on Arkadiko. In that case we use app.sign and pass the following payload:

0000000001040025a6b5c2c50a2abbff700b87c8dfe29bda77523b0000000000000003000000000000e41800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003020000000101021625a6b5c2c50a2abbff700b87c8dfe29bda77523b16dbd1c48f77bf2f9506a3d79117fc1c7eda3b89100f577261707065642d426974636f696e0f777261707065642d626974636f696e05000000000015e3070216982f3ec112a5f5928a5c96a914bd733793b896a51f61726b6164696b6f2d7661756c74732d6f7065726174696f6e732d76312d320a6f70656e2d7661756c740000000b0616982f3ec112a5f5928a5c96a914bd733793b896a51b61726b6164696b6f2d7661756c74732d746f6b656e732d76312d310616982f3ec112a5f5928a5c96a914bd733793b896a51961726b6164696b6f2d7661756c74732d646174612d76312d310616982f3ec112a5f5928a5c96a914bd733793b896a51b61726b6164696b6f2d7661756c74732d736f727465642d76312d310616982f3ec112a5f5928a5c96a914bd733793b896a52061726b6164696b6f2d7661756c74732d706f6f6c2d6163746976652d76312d310616982f3ec112a5f5928a5c96a914bd733793b896a51c61726b6164696b6f2d7661756c74732d68656c706572732d76312d310616982f3ec112a5f5928a5c96a914bd733793b896a51461726b6164696b6f2d6f7261636c652d76322d330616dbd1c48f77bf2f9506a3d79117fc1c7eda3b89100f577261707065642d426974636f696e010000000000000000000000000015e307010000000000000000000000001ddca7400a0516c9a03720732a3148129a121f58d2ba37f6c649450100000000000000000000000000000000

That also fails and is rejected by the Ledger device with:

errorMessage: "Data is invalid : Authorization type not supported"
returnCode: 27012

In both above cases I am using a Ledger Nano X

I tested the data you shared and it is a contract call:

parsed: ParsedObj { tag: Transaction, obj: Transaction { version: Mainnet, chain_id: 1, transaction_auth: Standard(TransactionSpe
ndingCondition { signer: SpendingConditionSigner { data: [0, 37, 166, 181, 194, 197, 10, 42, 187, 255, 112, 11, 135, 200, 223, 22
6, 155, 218, 119, 82, 59, 0, 0, 0, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0, 0, 228, 24] }, signature: Singlesig(SinglesigSpendingCondition([
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0])) }), transaction_modes: [3, 2], post_conditions: PostCondit
ions { conditions: [[1, 2, 22, 37, 166, 181, 194, 197, 10, 42, 187, 255, 112, 11, 135, 200, 223, 226, 155, 218, 119, 82, 59, 22, 
219, 209, 196, 143, 119, 191, 47, 149, 6, 163, 215, 145, 23, 252, 28, 126, 218, 59, 137, 16, 15, 87, 114, 97, 112, 112, 101, 100,
 45, 66, 105, 116, 99, 111, 105, 110, 15, 119, 114, 97, 112, 112, 101, 100, 45, 98, 105, 116, 99, 111, 105, 110, 5, 0, 0, 0, 0, 0
, 21, 227, 7]], num_items: 4, current_idx: 0 }, payload: ContractCall(TransactionContractCall([22, 152, 47, 62, 193, 18, 165, 245
, 146, 138, 92, 150, 169, 20, 189, 115, 55, 147, 184, 150, 165, 31, 97, 114, 107, 97, 100, 105, 107, 111, 45, 118, 97, 117, 108, 
116, 115, 45, 111, 112, 101, 114, 97, 116, 105, 111, 110, 115, 45, 118, 49, 45, 50, 10, 111, 112, 101, 110, 45, 118, 97, 117, 108
, 116, 0, 0, 0, 11, 6, 22, 152, 47, 62, 193, 18, 165, 245, 146, 138, 92, 150, 169, 20, 189, 115, 55, 147, 184, 150, 165, 27, 97, 
114, 107, 97, 100, 105, 107, 111, 45, 118, 97, 117, 108, 116, 115, 45, 116, 111, 107, 101, 110, 115, 45, 118, 49, 45, 49, 6, 22, 
152, 47, 62, 193, 18, 165, 245, 146, 138, 92, 150, 169, 20, 189, 115, 55, 147, 184, 150, 165, 25, 97, 114, 107, 97, 100, 105, 107
, 111, 45, 118, 97, 117, 108, 116, 115, 45, 100, 97, 116, 97, 45, 118, 49, 45, 49, 6, 22, 152, 47, 62, 193, 18, 165, 245, 146, 13
8, 92, 150, 169, 20, 189, 115, 55, 147, 184, 150, 165, 27, 97, 114, 107, 97, 100, 105, 107, 111, 45, 118, 97, 117, 108, 116, 115,
 45, 115, 111, 114, 116, 101, 100, 45, 118, 49, 45, 49, 6, 22, 152, 47, 62, 193, 18, 165, 245, 146, 138, 92, 150, 169, 20, 189, 1
15, 55, 147, 184, 150, 165, 32, 97, 114, 107, 97, 100, 105, 107, 111, 45, 118, 97, 117, 108, 116, 115, 45, 112, 111, 111, 108, 45
, 97, 99, 116, 105, 118, 101, 45, 118, 49, 45, 49, 6, 22, 152, 47, 62, 193, 18, 165, 245, 146, 138, 92, 150, 169, 20, 189, 115, 5
5, 147, 184, 150, 165, 28, 97, 114, 107, 97, 100, 105, 107, 111, 45, 118, 97, 117, 108, 116, 115, 45, 104, 101, 108, 112, 101, 11
4, 115, 45, 118, 49, 45, 49, 6, 22, 152, 47, 62, 193, 18, 165, 245, 146, 138, 92, 150, 169, 20, 189, 115, 55, 147, 184, 150, 165,
 20, 97, 114, 107, 97, 100, 105, 107, 111, 45, 111, 114, 97, 99, 108, 101, 45, 118, 50, 45, 51, 6, 22, 219, 209, 196, 143, 119, 1
91, 47, 149, 6, 163, 215, 145, 23, 252, 28, 126, 218, 59, 137, 16, 15, 87, 114, 97, 112, 112, 101, 100, 45, 66, 105, 116, 99, 111
, 105, 110, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 21, 227, 7, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 29, 220, 167, 64, 10, 5,
 22, 201, 160, 55, 32, 115, 42, 49, 72, 18, 154, 18, 31, 88, 210, 186, 55, 246, 198, 73, 69, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
0, 0, 0, 0, 0])), signer: Invalid, remainder: [] } }

not sure what is happening, are you able to test with a nanosplus? on what OS are you running this? macOS, could it be a communication error with the device?

[314159265359879]

@neithanmo we already tested this with nano S+, with firmware 1.1.1 and more recently with 1.1.2. I tested with Windows machine. I am not sure about Pete's OS.

[pete-watters]

@neithanmo I am testing it on Mac OS

[neithanmo]

I will close for now, provided data did not trigger any error in our integration test or our unit testing.

feel free to open again and provide more detail