Aggregate bonded gets dropped due to incorrect max fee

[Wayonb]

With Aggregate bonded transaction its harder to calculate the min fee required for the transaction to get process. The problem is due to the cosigner signatures is not included in the submission of the tx to the server. The SDK has two proposals to fix this issue.

1. Use the multisig account graph as state by @evias.

What about using the multisig account graph to determine the number of required signers ?

@Wayonb @fboucquez @rg911 http://api-01.us-west-1.symboldev.network:3000/account/TAWJ2M7BGKWGBPOUGD5NDKHYDDQ7OQD26HJMMQS2/multisig/graph

Knowing that aggregate bonded also have there own "announcement method". I can see this help because the account multisig graph can be iterated over to determine the needed total number of minApproval

Originally posted by @evias in https://github.com/nemtech/symbol-sdk-java/issues/251#issuecomment-601109696

This is gives an accurate min fee but has a lot of cost to figure out all the required cosigners.

2. Always calculate the max fee using the max cosigners as stated by @dgarcia360.

   One costly option for the users would be adding maxCosignaturesPerAggregate * cosignatureSize to the aggregate transaction size. Users can still pay fewer fees if they want to adjust better the cost by reducing the transaction's maxFee multiplier.

    MaxCosignaturesPerAggregate can be retrieved from https://github.com/nemtech/catapult-server/blob/master/resources/config-network.properties#L47
   
    This change requires to have a configuration parameter on the SDK to define which is the default maxCosingaturesPerAggregate since it might vary per network. The value could also be retrieved from REST if not specified.
   

[rg911]

However, if we have to call the multisigGraph, we lose the offline signing ability right?
What about sharing the responsibility between the SDK and the user? See my options below:

1. Disable setMaxFee on aggregate transactions which calculate the fees from transaction.size. Create a service for aggregate transactions to calculate maxFee by calling the multisigGraph. It will share the responsibility to the user who needs to make sure they call the service to get the right fee figure, otherwise transaction can be rejected.

2. Add a new field MaxNumberOfCosigners to the aggregate transactions. Similar to option 1 which the user needs to find out how many cosignatures expected. The difference is this field is a free entry one. It can be >, < or == the cosigners defined in multisigGraph. The potential risk is if the tx initiator misplaced the figure the transaction might get rejected. The extended version for this option is we can add a check if more cosignatures received.

The main point here is how we can keep the offline signer ability.

Any other ideas? @Wayonb @dgarcia360 @fboucquez @evias

[rg911]

I think another option is as @Wayonb mentioned in Java SDK.

• Take the feeMultiplier as an argument in signTransactionGivenSignatures with some rough calculations:

1. If fee provided with direct input (not using setMaxFee with multiplier`: NewFee = (oldFee / oldSize) * newSize
2. If fee provided using the setMaxFee: Add a private var to Transaction to hold the feeMultipler, then in the signTransactionGivenSignatures method replace old fee with: NewFee = newSize * feeMultiplier

Root condition for replacing is oldMaxFee < newMaxFee

[dgarcia360]

we lose the offline signing ability right correct, that's why I didn't like to add this option by default.

To solve the optimal value issue, I propose to mix the options that @rg911 proposed to get the best of them. Note that the dev should still have the ability to define the absolute maxFee that they want to expend for the transaction (e.g. no more than 10 symbol.xym). Here there are the changes required:

• Create a service for aggregate transactions to calculate maxFee the number of cosignatories required by calling the multisigGraph.
• The aggregate transaction function setMaxFee(feeMultiplier: number) could be changed to setMaxFee(feeMultiplier: number, requiredCosignatures: number). The function now takes as the second parameter the value retrieved from the new service, maxCosignaturesPerAggregate defined in the network properties, or any other desired value.