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

They point out that BitVM cannot be used to achieve the desired goal, which is to restrict an actuary to only signing for a particular spend once. The proposed mechanism in the original post suggests fixing 'R' to force reuse. However, this approach requires a change in Bitcoin consensus on top of SIGHASH_ANYPREVOUT. ZmnSCPxj suggests that making such a change would not only enable Decker-Russell-Osuntokun, but also make it more convenient to make offchain mechanism state changes asynchronously with participants and the actuary signing off on new transactions.ZmnSCPxj proposes a possible solution involving a program that checks if two signatures sign different things but have the same public key. If this program validates, it indicates that the actuary has cheated and appropriate actions can be taken. However, they mention that BitVM triggers on dishonest execution of the program, so the program cannot be used as-is. Honest execution of the program leads to the BitVM contract resolving via timeout.ZmnSCPxj explores the idea of changing the "polarity" of the logic to punish the actuary, but this would require the actuary to act as the validator instead of the prover. They explain that it would make little sense for the aggrieved participant, who expected the actuary to not violate the sign-only-once rule, to be in the prover position. They also note that if a program was written to show that there are no other signatures with a different message but the same public key, it would be easy to make that program pass by denying it any other signature inputs. Additionally, the actuary can always commit to an input that lacks the second signature it made.ZmnSCPxj further explains that the actuary can run a program outside of BitVM, making it pointless to have the signing algorithm written in BitVM. They highlight that in the actuarial system, the actuary should provide something that would make a transaction immediately confirmable, unlike in BitVM where the honest execution of a BitVM program is the timeout. The actuary should also be restricted to showing this for only one transaction, not any other transactions.In conclusion, ZmnSCPxj states that they have not been able to figure out how to use BitVM to replace the current forced 'R' reuse mechanism for preventing multiple commitments by the actuary.