Add ability for signers to sign each individual key spend of a BTC deposit consolidation transaction.
Context
Signers are meant to consolidate deposit transactions via batching and to ensure a single utxo at all times in the wallet. This means that each individual transaction must be considered in the form of an input to the deposit transaction some of which will be coming from places that are undesireable and should therefore be voted on individually.
This implies that some deposits could be rejected as they do not get enough signatures in which case they should be removed from the resulting transaction entirely (submitted as the stx transaction as "no quorum"). This also implies that multiple transactions could result from the "nonce" round of a sign request. These transactions will need to build on each other. (suppose 1 deposit is liked by the first 70% of signers and the 2nd deposit is liked by the last 70%, this will require two transactions to satisfy quorum and they should be chained together as the output of the first is required for the second)
Expected Approach
Start with the simpler one at a time approach. Perform a signing round one at a time over a single BTC transaction per deposit/every single input. If possible, add ability to send a vec of these inputs through stacker db and return shares for each individually.
Note for a single BTC transaction consisting of N inputs, you will need to run N+1 signing rounds (one per input, one across the whole BTC transaction including inputs)
Description
Add ability for signers to sign each individual key spend of a BTC deposit consolidation transaction.
Context
Signers are meant to consolidate deposit transactions via batching and to ensure a single utxo at all times in the wallet. This means that each individual transaction must be considered in the form of an input to the deposit transaction some of which will be coming from places that are undesireable and should therefore be voted on individually.
This implies that some deposits could be rejected as they do not get enough signatures in which case they should be removed from the resulting transaction entirely (submitted as the stx transaction as "no quorum"). This also implies that multiple transactions could result from the "nonce" round of a sign request. These transactions will need to build on each other. (suppose 1 deposit is liked by the first 70% of signers and the 2nd deposit is liked by the last 70%, this will require two transactions to satisfy quorum and they should be chained together as the output of the first is required for the second)
Expected Approach
Start with the simpler one at a time approach. Perform a signing round one at a time over a single BTC transaction per deposit/every single input. If possible, add ability to send a vec of these inputs through stacker db and return shares for each individually.
Note for a single BTC transaction consisting of N inputs, you will need to run N+1 signing rounds (one per input, one across the whole BTC transaction including inputs)
This is closely related to
Acceptance Criteria