● Continued schnorr/taproot discussion: this week, Russell O’Connor started a thread on the Bitcoin-Dev mailing list continuing a previous discussion about having signatures commit to the position of the opcode that’s expected to evaluate that signature (e.g. the opcodes OP_CHECKSIG , OP_CHECKSIGVERIFY , or tapscript’s new OP_CHECKSIGADD ). O’Connor argues that this commitment provides additional protection for people who use scripts with multiple branches that allow the script to be satisfied in several different ways using signatures from more than one user. Without this protection, it might be possible for Mallory to ask Bob to sign for branch A when Mallory is really going to use that signature in branch B. An existing opcode, OP_CODESEPARATOR , helps deal with such situations, but it’s not well known and so addressing the concern directly could improve safety and possibly eliminate the need to include OP_CODESEPARATOR in tapscript.

Following some IRC discussion by several participants, Anthony Towns replied with a suggested alternative: scripts that are susceptible to this problem should have their branches separated into multiple taproot leaves each with just one code branch. Tapscript signatures already commit to the script being executed, so a signature that’s valid for one script can’t be used in another script. Towns also described why committing only to the position might not guarantee protection against repositioned signatures. Although he did describe a method that he thinks could provide superior protection, he believes it’s not particularly useful compared to just keeping OP_CODESEPARATOR in tapscript.

In a separate schnorr-related topic, ZmnSCPxj wrote a post about the challenges of safely using the MuSig signature aggregation protocol with sub-groups. For example, ZmnSCPxj’s nodelets proposal suggests Alice and Bob could jointly control funds through a single LN node using the aggregation of their keys, (A, B). Their joint node could then open a channel to Charlie’s node, using MuSig aggregation there too, ((A, B), C). However, ZmnSCPxj describes why this might be unsafe given Wagner’s algorithm as described in last week’s newsletter. Also described are several alternative schemes that attempt to work around the problem.