Provide an alternative way to handle signing transactions when the transaction fails with the node that is specified

[SimiHunjan]

The current SDK algorithm for signing transactions is to sign a transaction multiple times for the chosen healthy nodes to rely on for executing the transaction. For WEB and NATIVE until now, this signature was only one, because we’ve got only one node in the list.

This will affect the users with Hardware Wallets, which will be prompted to sign a transaction for every node (unfortunately this is by the current workflow of the SDK).

We can think about a potential fix for this as follows: We can sign a transaction only for a node that the SDK will try to execute the transaction through it. BUT If this node fails, the transaction needs to be re-signed again. What is different than the previous approach? The difference is that the user will be prompted to re-sign the transaction only if this node fails and another is chosen for processing the transaction.

One workaround that the Hashpack team asked me about and I’ve provided to them is to specify with the 1setNodeAccountIds1 a single node, when a hardware wallet is used.

The question is how we want the SDK to behave, should we sign the transactions one time for the multiple nodeAccountIds, or do we want to re-sign them every time the node failed to execute a transaction?

[SimiHunjan]

@nickpoorman @steven-sheehy @rwalworth @bugbytesinc @izik1

[mohsin-hedera]

This becomes more relevant with Community Nodes when these nodes can add/drop outside of the maintenance window. Broadcast of the signed transaction without worrying about duplication and costs would make sense.