It should be OK to call this method even if a TX already has
a signature. (Re-)setting the value does not alter the TX message
digest and so it does not invalidate any existing signatures (the way
changing the TX's locktime would). The caller of course must be
sure to only set the consensusBranchId that is valid for the current
network, and there is only one valid option per network.
Removing this check is required in downstream settings where an
application uses this library to add multiple signatures to a
multisig input and needs to overide the default consensusBranchId
each time.
matthewzipkin-bitgo
commented
3 years ago
see https://github.com/BitGo/bitgo-utxo-lib/pull/89#discussion_r506369556
It should be OK to call this method even if a TX already has a signature. (Re-)setting the value does not alter the TX message digest and so it does not invalidate any existing signatures (the way changing the TX's
locktimewould). The caller of course must be sure to only set the consensusBranchId that is valid for the current network, and there is only one valid option per network.Removing this check is required in downstream settings where an application uses this library to add multiple signatures to a multisig input and needs to overide the default consensusBranchId each time.
TICKET BG-24753