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

The email introduces the concept of offchain mechanisms in blockchain technology, specifically focusing on the Bitcoin blockchain. It explains that users can go offline and then come online to synchronize and broadcast transactions to the mempool, which are confirmed by miners. However, this becomes difficult in offchain mechanisms like Lightning channels, where users need to be always online. The sender proposes a solution called the actuary role, similar to miners in the blockchain, who only decide transaction ordering without having custody of funds.To enable the actuary role, two softforks, SIGHASH_ANYPREVOUT and OP_CHECKSEPARATEDSIG, are suggested. The advantages of using an N-of-N signatory set in offchain mechanisms are discussed, providing consensus and preventing a majority from forcing movement of funds against a participant's will. However, all participants need to be online to sign a new state, which stalls the protocol if one participant is offline.The concept of an offchain "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 sender 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 hostage them, and assurance that participants can drop the mechanism onchain 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 SIGHASH_ANYPREVOUT 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 is provided with 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 onchain, the confirmed transaction can be immediately confirmed onchain 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 onchain 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.