[Design]: Signing bitcoin transactions

[djordon]

Design - Signing bitcoin transactions

This ticket holds the design of the signing and validating protocol and how it fits into constructing bitcoin transactions.

1. Summary

Our designs for constructing, signing, and validating bitcoin transactions has not been completed yet. Our current code base does no validation for the bitcoin transaction yet. The proposed approach is to have most of the validation logic be handled implicitly by matching on signature digests.

2. Context & Purpose

We need to have a protocol where bitcoin transactions are validated by a consensus majority of the signers before a bitcoin transaction can be created and signed.

3. Design

3.1 The proposed Signer bitcoin protocol

When it comes time to construct a bitcoin transaction, the following will happen:

1. The coordinator fetches all relevant deposit and withdrawal requests. It also fetches the last fees paid for transactions in the mempool.
2. The coordinator divides the request IDs into an ordered subset of request IDs. The process for doing so is outlined in #52.
3. The coordinator constructs a sign request message containing the ordered list of request IDs, the last fees paid, and the current bitcoin market fee rate and sends that to the other signers.
4. Each signer, upon receiving the sign request message, uses their own knowledge of the requests identified by the IDs to construct a chain of bitcoin transactions called a transaction package. Each transaction in the package is formed from one of the disjoint subsets created in step (2).
5. Once a signer has a transaction package, they then responds to the coordinator with the transaction digests that they are willing and able to sign. Each signer stores these digests, along with whether they will sign for them, in their database.
6. The coordinator also constructs a transaction package using the same request IDs from (2) and leads a signing round for the digests that it creates.
7. When deciding whether to participate in a signing round, each signer matches on the digest-to-sign that they receive from the coordinator.
8. After the transaction is signed, the coordinator broadcasts the transaction.

3.2 Protocol sensitivity

Each digest from (5), called a sighash, is constructed as a SIGHASH_ALL digest that protects all inputs and outputs from modification. Each signer constructs such a digest for each input to the transaction. A signer will only agree to sign a digest if the following is true:

1. All inputs and outputs in the transaction associated with the digest is “acceptable” to the signer (as in the block checker doesn’t block any of the requests),
2. The signer can sign for the digest. If the digest is for an input that is locked by an aggregate key that they are not a party to, then they cannot sign for the associated digest.
3. The fees for including the requests in the transaction does not exceed any of their max fees.

Lastly, the signers need to construct the exact same digests for this to work. This requires them to have the same information about:

• The details of the deposit request
• The withdrawal amount and recipient
• How the signers voted on each request
• The amount locked in the signers’ UTXO,
• The same algorithm for transforming the prevailing fee rate and the last fee into a transaction fee. This is defined in the code here.
• The same algorithm for computing the assessed fee, which was outlined in #182.
• The same ordering of inputs and outputs. The first input of a Signer transaction is the signers’ input, while the remaining inputs are from deposits and are sorted by their outpoint. The first output is the signers new UTXO, the second output is an OP_RETURN output, whose contents are defined in #483. The remaining outputs correspond to withdrawals, and they are sorted by their request ID.

If a signer deviates from any of these details then they will have different signature digest from the other signers, and so won’t participate in a signing round. Therefore, the proposed protocol requires a consensus majority of the signers to agree on all of these details.

3.3 Design Diagram

Below is a protocol diagram of the proposed signing protocol. There, we use the sighash terminology to refer to the digest that needs to be signed.

3.4 Considerations & Alternatives

The alternative revolves around sending more fully fledged out transactions. In this flow, the coordinator submits the transactions that need their digests signed.

Pros

This approach has one main benefits: it allows the signers to pinpoint where there is some disagreement in the details of the transaction. In the proposed approach you can validate that the deposits and withdrawals are acceptable, but if there is a mismatch in any of the other details then all we know is that there is a mismatch somewhere.

Cons

This approach is just takes more time do than the proposed approach. In the proposed approach we match on sighashes, and it is just as exacting as the alternative. Each signer must be using the same algorithms and data for transaction construction.

3.5 Areas of Ambiguity

---

Closing Checklist

• The design proposed in this issue is clearly documented in the description of this ticket.
• Everyone necessary has reviewed the resolution and agrees with the proposal.
• This ticket has or links all the information necessary to familiarize a contributor with the design decision, why it was made, and how it'll be included.