Actuarial System To Reduce Interactivity In N-of-N (N > 2) Multiparticipant Offchain Mechanisms

The sender introduces the concept of an actuary role, similar to miners in the blockchain, who are responsible for deciding transaction ordering without having custody of funds. Two proposed softforks, namely SIGHASH_ANYPREVOUT and OP_CHECKSEPARATEDSIG, are suggested to enable this actuary role.

The advantages of using an N-of-N signatory set in off-chain mechanisms are highlighted, providing consensus and preventing a majority from forcing movement of funds against a participant's will. However, it is noted that all participants need to be online to sign a new state, which can stall the protocol if one participant is offline.

The concept of an off-chain "mempool" is introduced, where the state of the mechanism is considered as pairs of Bitcoin SCRIPT and satoshis, instantiated as actual transaction outputs. Participants can create transactions within the current state and send money to each other, but these transactions remain unconfirmed until they are signed off by all participants.

To address the confirmation issue without custodianship, the email suggests adding the actuary to the contract controlling the funds with a specific R value, preventing R reuse and enforcing single-spend. This ensures non-custodiality while maintaining an N-of-N requirement for spending.

The desired properties for the actuary role are highlighted, including the ability to select one transaction, inability to spend funds unilaterally or hold them hostage, and assurance that participants can drop the mechanism on-chain and recover their funds if the actuary stops responding. A suggested method to ensure these properties is infecting the SCRIPT of all outputs with (sign-only-once(M) || CSV) && C.

The email also discusses the SIGHASH_ANYPREVOUT feature in Bitcoin transactions and its relationship to the actuary role. With SIGHASH_ANYPREVOUT, participants can confirm transactions "confirmed" by the actuary even if the actual transaction ID changes.

An example scenario is provided to illustrate the proposed mechanism, involving three participants (A, B, C) and an actuary (M). Each participant has a base contract, and the actuary signs transactions using a fixed R nonce. When A wants to send money to B, they create a transaction with two new outputs. A solicits a single-spend signature from the actuary to ensure B's assurance against double-spending. If dropped on-chain, the confirmed transaction can be immediately confirmed on-chain as well.

To update the state of the mechanism, the actuary proposes a new state to each participant. Participants only need to validate expected outputs, reducing bandwidth requirements and providing a scaling advantage. All participants must sign off on each state update, preventing invalid states and dropping the current state on-chain if needed.

Custodial solutions are avoided in this design to minimize control over coins. The actuary role only confirms transactions and cannot move funds without consent, ensuring consensus from all participants. Participants can go offline and online while the actuary coordinates new states.