[Feature]: Account for changes in the signature threshold during packaging

[djordon]

Feature - Account for changes in the signature threshold during packaging

1. Description

We do not account for votes correctly when packaging requests into sweep transactions. We have two issues there:

1. We treat "I vote against" the same as "I cannot sign for this even if I wanted to" at the packaging level, which can lead to deposits falling through the cracks here and there.
2. We do not distinguish between the different thresholds for each of the inputs.

This is mainly a problem with deposits, where each deposit request may have a differing threshold or different associated signing set. Withdrawals are easier, signers only care about the set of signers who they can communicate with, which is the "current signing set", but the threshold that is associated with the current signing set may be ambiguous.

2. Technical Details

Packaging requests into a transaction should probably follow slightly different logic than what is currently in place. I think the logic should be as follows:

1. Explicitly consider the signers UTXO as an input, whose votes against is the aggregate votes against for the transaction.
2. Iterate through all the requests starting with deposits.
3. Filter deposit requests that do not have enough votes for the request.
4. Add a request to a sweep transaction if it's addition means that the signers will sign for all of the existing inputs in the transaction. Add it to a new transaction in the chain otherwise.

We'd still have the existing limits on the number of deposits and withdrawals, but so long as those aren't breached the logic above should work.

Note that we'd want to correctly account for the the different kinds of votes signers can "receive" from another signer about a request: a signer can sign and will, a signer can't sign so won't, a signer can sign but won't, and a signer can just not vote. We currently consider the last three states as equivalent during packaging, but we should only consider the last two as equivalent.

2.1 Acceptance Criteria

• The packaging does not incorrectly exclude requests even when the signer set or signature threshold changes.

3. Related Issues and Pull Requests (optional)

[cylewitruk]

1. Explicitly consider the signers UTXO as an input, whose votes against is the aggregate votes against for the transaction.

What do we actually gain from adding this?

3. Filter deposit requests that do not have enough votes for the request.

This should probably be expanded to include ensuring that we have deposit.aggregate_key.threshold signers in the current signing set who are able to spend from that deposit's scriptpubkey.

[djordon]

1. Explicitly consider the signers UTXO as an input, whose votes against is the aggregate votes against for the transaction.

What do we actually gain from adding this?

I think that it's necessary in order to account for some edge cases. All of the examples that come to mind involve situations where the signers' UXTO has a different signing set, with a different threshold, than the deposits in the transaction. One thing that I should more explicitly mention here is that this aggregation is still bitmap based, like in our current approach, so we still capture the cases where one signer is mad at the world and votes against everything. Much of the current logic carries over.

3. Filter deposit requests that do not have enough votes for the request.

This should probably be expanded to include ensuring that we have deposit.aggregate_key.threshold signers in the current signing set who are able to spend from that deposit's scriptpubkey.

Yeah, I should explicitly mention that. But the backdrop here is that we are still following much of the existing logic that we have in plance, which already accounts for this fact. I don't think that we should change that.

[cylewitruk]

All of the examples that come to mind involve situations where the signers' UXTO has a different signing set, with a different threshold, than the deposits in the transaction.

But can't this be implicitly handled by the per-request votes?

Say we've got keys A and B with thresholds of 11 and 10 respectively (signer sets A'11 and B'10):

If B'10 is the current set and goes to package a deposit from A'11, we should require that B'10 has 11 "yes votes" for that deposit from signers in B'10 who can also sign for A (or otherwise were a part of A'11). This deposit should be filtered because there's no way that B'10 can produce 11 votes.

If A'11 were the current set and the above were reversed, and assuming that it's comprised wholly of signers from B'10 plus one new, then a deposit spent to B could meet the criteria.

If A'11 only contained 9 signers from B'10 (e.g. lost 1, added 2), then the criteria couldn't be met since B'10 only has 9 signers able to spend B.

etc. etc.

Maybe I'm missing something?

[djordon]

But can't this be implicitly handled by the per-request votes?

I don't think so. The example that came to mind is a deposit request locked with a keys a that is a 2-of-4 aggregate key, a withdrawal request, and the current signing set that locked with a 5-of-7 aggregate key. If the deposit request has 2 votes against and with withdrawal request has 1 vote against, it could be the case where the one vote against the withdrawal request doesn't impact the deposit request at all but the signers would vote against a transaction servicing both requests together.