Signer/Coordinator Brain Dump

[jferrant]

This is a bit of a brain dump of the Signer process.

Signer Needs

Need to have from either stacks node/smart contract/stacker db @jo-tm @netrome @jcnelson @soju-drinker @will-at-stacks @xoloki :

• Ability to retrieve pending sBTC transactions (unprocessed/unfulfilled transactions)
• Ability to check if an sBTC transaction has already been processed
• Ability to retrieve all signer's IDs and their public keys and corresponding vote shares
• Ability to determine signers of current round and determine signers of previous round (due to weird wallet handoff issues)
• Ability to broadcast and retrieve Signature Share Requests/Signature Share Responses for Signer communication (stacker DB?)
• Ability to query smart contract for signer public key given either the signer's id or its public key (the resulting public key may be different as it could be a delegate public key)

NOTES:

• Every signer can take on the role of a coordinator and all could simultaneously post fulfilled BTC transactions for example so long as the resulting BTC transaction is identical across all signers so mempool can filter them out
• See the Master sBTC sheet for a breakdown of BTC and STX transactions: https://docs.google.com/spreadsheets/d/12L96AeK6ZCxFls87Gil8FYDkWKWxWW1NtSDpB5Bv_sg/edit#gid=330357363

For an idea of how the signer and coordinator (note a coordinator is a signer but a specific subrole) flows look, see below text and the following sequence diagrams:

Signer Flow

1. Register Signer public key in smart contract

• Note this could be a delegate key so prob will need to be able to store a public key mapped to another public key in the smart contract (one being the original public key and the other being the delegate public key. In the case of no delegation, they would be the same)

2. Retrieve all other signers’ info:


• Signer IDs and their corresponding public keys

• Vote IDs (vote shares) and their corresponding signer public keys
• This will most likely have to be a combo of smart contract calls and stacks node call
• NOTE: Both Signer IDs and Vote IDs must be monotonically increasing and unique

3. Retrieve DKG Request (if one is due) from the elected Coordinator
4. Write DKG Responses to stacker DB
5. Retrieve all sBTC transactions
6. Process sBTC transactions

• Retrieve Sign Request from StackerDB from the Coordinator of a specific tx
• Check tx and sign approve/deny accordingly
• Send Sign Response to StackerDB

Coordinator Flow

1. Check sBTC wallet public key

If outdated and you are a NEW coordinator:

2. TRIGGER SIGN REQUEST for DKG Round (FROST/FIRE/ROAST logic to handle unresponsive signers)

• Update sBTC wallet public Key
• Wait for sBTC wallet handoff from old coordinator

If updated and you are an OLD coordinator:

2. TRIGGER SIGN REQUEST for Wallet Handoff using new sBTC wallet address

3. Retrieve Pending sBTC Transactons

• These transactions should be only unprocessed ops. This logic to keep track of already processed transactions should be abstracted away as best as possible from the coordinator
• Or if they are all ops including processed ones, must be able to filter out processed ones after the fact
• Or any triggered BTC or STX transaction subsequently must be identical down tot eh utxos used to fulfill them so that mempool filters them out

4. TRIGGER SIGN REQUEST for sBTC deposit/withdrawal reveal
5. Broadcast STX transaction to mint/redeem sBTC tokens

• The STX transaction should be called contingent on the success of the BTC transaction: See https://github.com/Trust-Machines/stacks-sbtc/blob/82f40002dca2891e6fd3e43c12a159023a68299d/sbtc-mini/contracts/clarity-bitcoin.clar#L425

TRIGGER SIGN REQUEST

• Send Sign Request to every signer
• Retrieve Partial Signature Shares
• Aggregate partial signature shares
• Broadcast resulting signed BTC transaction

Signer Sequence Diagram

sequenceDiagram
    participant Signer as Signer
    participant SmartContract as Smart Contract
    participant StacksNode as Stacks Node

    Note over Signer, StacksNode: Key Registration
    Signer->>SmartContract: Register Signer Public Key
    SmartContract->>SmartContract: Store Public Key Mapping

    Note over Signer, StacksNode: Signer Data Retrieval
    Signer->>StacksNode: Retrieve Signers' Info
    StacksNode-->Signer: Signer IDs/Public Keys/Vote Shares
    Signer->>SmartContract: Retrieve Signer's Public Key
    SmartContract-->Signer: Public Key
    
    Note over Signer, StacksNode: Process sBTC transactions
    Signer->>StacksNode: Retrieve sBTC transactions
    StacksNode-->Signer: sBTC Transactions
    Signer->>Signer: Check Coordinator of Transaction
    
    Note over Signer, StacksNode: Process Sign Requests
    Signer->>StacksNode: Retrieve Sign Requests
    StacksNode-->Signer: Sign Requests
    Signer->>Signer: Calculate Coordinator Public Key
    Signer->>StacksNode: Verify Sign Request

    alt DKG Sign Request
        Signer->>StacksNode: DKG Sign Response
    else Tx Sign Request
        Signer->>Signer: Verify Transaction
        Signer->>Signer: Sign Approve/Deny
        Signer->>StacksNode: Tx Sign Response
    end

Loading

Coordinator Sequence Diagram

sequenceDiagram
    participant Coordinator as Coordinator
    participant StacksNode as Stacks Node
    participant BitcoinNode as Bitcoin Node

    Note over Coordinator, BitcoinNode: sBTC Wallet Handoff
    Coordinator->>StacksNode: Get sBTC wallet public key
    alt Outdated Wallet and New Coordinator
        Coordinator->>StacksNode: DKG Sign Request
        Coordinator->>StacksNode: Get DKG Sign Response
        StacksNode-->Coordinator: DKG Sign Response
        Coordinator->>Coordinator: Aggregate Response Shares
        Coordinator->>StacksNode: Set sBTC wallet public key
    else Updated Wallet and Old Coordinator
        Coordinator->>Coordinator: Create BTC wallet handoff tx
        Coordinator->>StacksNode: Tx Sign Request
        Coordinator->>StacksNode: Get Tx Sign Response
        StacksNode-->Coordinator: Tx Sign Response
        Coordinator->>Coordinator: Aggregate Shares
        Coordinator->>BitcoinNode: Wallet Handoff tx
    end
    
    Note over Coordinator, BitcoinNode: Process sBTC Ops
    Coordinator->>StacksNode: Get Pending sBTC Ops
    StacksNode-->Coordinator: Pending sBTC Ops
    Coordinator->>Coordinator: Fulfill Withdrawal Requests
    Coordinator->>StacksNode: Tx Sign Request
    Coordinator->>StacksNode: Get Tx Sign Response Shares
    StacksNode-->Coordinator: Tx Sign Response Shares
    Coordinator->>Coordinator: Aggregate Shares
    Coordinator->>BitcoinNode: Deposit/Withdrawal Reveal tx
    Coordinator->>BitcoinNode: fulfilled Withdrawal tx
    Coordinator->>StacksNode: mint/redeem STX tx

Loading

[netrome]

Nice brain dump. Some thoughts:

1. We don't have any information here revolving commit-reveal. I.e. how does the signer receive the unlock script from a user committing to a deposit request?
2. "Ability to check if an sBTC transaction has already been processed" - I'm not sure if the signers can rely on an external entity to provide accurate information on this. Any stacks node may not have up-to-date information and afaik StackerDB has the same properties. I.e. any external source of information may give false negatives to the question. The signers must themselves create a consistent view of which sBTC transactions that has been processed.
3. "Get coordinator public key". I'd imagine the signers being able to infer which signer is acting as a coordinator for each request without having to consult a smart contract or any other information beyond knowing the signer set and the information in the request.

[jferrant]

Another question?
How will handoff work if stacker db does not persist data between the two reward cycles?

during handoff, new signers need to communicate to produce the new DKG address

Old signers need to still communicate to produce the BTC wallet handoff transaction

Implies we need to have stacker db update for a handoff period to enable both signing sets to write to the db

Might be a good to enable old signers to verify the aggregate result of the new signers to construct the BTC wallet handoff/ensure that coordinator is not constructing a faulty BTC transaction to some unknown uncontrolled address (not just rely on the smart contract input)

[jcnelson]

How will handoff work if stacker db does not persist data between the two reward cycles?

It will persist data for as long as its controlling smart contract specifies. We can make it persist for two reward cycles, for example.

[jferrant]

Messages that need to be sent to Signers via stacker DB:

DKG Round Messages:
DKGBegin
DKGPublicShares,
DKGPrivateShares,
DKGEnd,

Tx Signing Round Messages
NonceRequest => Must Include Tx in Request
NonceResponse => This is where manual review has to happen (user commits to approving or denying a transaction)
SignatureShareRequest => Send only to the 70+ percent of people committing to some consensus (approve/deny)
SignatureShareResponse => If someone sends something other than their committed vote (or just a bad sig period), this is where sanctioning occurs. If bad sig results, trigger entirely new nonce request -> implies signers must keep state to prevent manual review of the same transaction

VRF Concerns

For DKG round:

• we need to have an elected leader for this portion as DKGPublic/Private shares will be different depending on who triggered the round meaning everyone needs to keep track of multiple DKG instances PLUS this is a CPU intensive calculation and should be avoided. This also could cause issues.
• Say Alice and Bob simultaneously submit a new sBTC wallet address. Alice wins over Bob (her STX contract call tx gets mined), the handoff occurs, and then Bob's STX contract call tx gets mined. This will result in an unnecessary update to the sBTC wallet address and in theory force an additional handoff by the current signers to themselves (or force them to wind back the address).
• If we enforce a leader via a contract, we can dictate who has write access to the smart contract sBTC wallet update function
• We def have to do VRF to ensure we don't have multiple DKG rounds simultaneously, however, we may need some sort of contract guarantee as well.

[netrome]

Speaking of simultaneous updates of the sBTC wallet address. We need to ensure that a signer is not able to submit a malicious dkg address. How do we ensure that the address submitted to the smart contract is in fact the same address that was generated in dkg?

[jferrant]

I think this would have to be verified by signers during the wallet handoff itself. See above comment about old signers verifying new signers dkg rounds to ensure that the smart contract and signer dkg round result match. At that point, setting the dkg address in the smart contract really is only required for things like the bridge to know where to send funds/to maintain persistent state.

Do we rely on stacks validators to validate it? @soju-drinker "The stacks validators should set the sBTC wallet public key after observing the signers dkg round result"

[xoloki]

Yeah, a malicious dkg coordinator will be caught during wallet handoff, because every signer can check whether the new public key is what it should be based on dkg public shares.

As long as we always tweak our taproot keys, there's no way for a byzantine actor to do anything malicious.

[netrome]

Wouldn't that allow a single signer in the new set to sabotage the whole round? Say someone participates in the staking pool with very little STX, but spams the chain to always put a garbage address as the sBTC wallet address. That would DoS the whole system in that case. Is that a risk we're willing to accept for 0.1 since it's already based on the assumption that signers are benevolent?

[jferrant]

Concern about spendability of denied UTXOs:

• If signers collectively decide not to mint sbtc for utxos received from a particular address, but that sender address never actually redeems them. We need to keep track of these utxos so we do not include them in the wallet handoff.

[netrome]

Indeed. Although probably it will be hard for us to accidentally spend a taproot UTXO since these require some special treatment to track and unlock.

[xoloki]

For taproot key spends with null merkle roots, it's a trivial spend which would any wallet scanning algo would likely pick up. Same for p2pk/p2pkh outputs. But yeah taproot script spends or key spends with a merkle root would be unlikely to be grabbed unintentionally.

I put a collection of other conclusions and questions @jferrant and I discussed today here: stacks-network/sbtc#44 (comment)

[netrome]

Perfect, yeah I saw it. Great stuff! I sent an invite to chat about this before our team meet. Let me know if you prefer another time.