The collaborative path refers to using the taproot-tweaked public key to sign without revealing any scripts. However, the bip-taproot proposal disallows certain SIGHASH flags, including SIGHASH_NOINPUT/SIGHASH_ANYPREVOUT. ZmnSCPxj argued that the collaborative path is only useful in cooperative closures, as parties can agree to spend the funding txo without requiring SIGHASH_ANYPREVOUT. In an email exchange between Bastien TEINTURIER and ZmnSCPxj, they discussed the use of the collaborative path in taproot-tweaked public keys. The bip-taproot proposal does not allow certain SIGHASH types, except in bip-tapscript. ZmnSCPxj reiterated that the collaborative path is only relevant in cooperative closures, as fallbacks already exist for cooperation failure.A discussion on the Bitcoin-dev mailing list revolved around the use of the collaborative path in Taproot. Christian Decker expressed concerns about its use with update_tx, as it requires signing with noinput and lacks a way to specify the chaperone key. The conversation then shifted to eltoo scripts, including an update transaction, settlement transaction, and HTLC claim/refund transactions using muSig. Various aspects of these proposed scripts were discussed, such as combining multiple transactions, adding fees, and calculating private keys using ECDH between peers.Participants in another conversation discussed the Eltoo update mechanism for Lightning Network and potential optimizations with taproot/tapscript. They explored the possibility of using a shared private key to minimize extra space and suggested using MuSig to reduce OP_CHECKMULTISIG/OP_CHECKSIGADD. They also proposed eliminating the need for explicit OP_CHECKSEQUENCEVERIFY and separate keys for state and update paths. The conversation touched on chaperone signatures, anyprevoutanyscript/noinput in taproot collaborative spends, and the compatibility of Eltoo with taproot.ZmnSCPxj proposed minimizing extra space by collapsing 1-of-2 multisigs into a single-sig using a shared private key specific to the protocol instance. MuSig was suggested to reduce the need for OP_CHECKMULTISIG/OP_CHECKSIGADD. Update transactions would have nSequence set to 0, while state transactions would have a non-zero value. Participants would exchange anyprevoutanyscript signatures during channel updates, and the chaperone signature could be provided by either party at transaction broadcast time. The use of any SIGHASH other than SIGHASH_ALL was also discussed without significant objection.Christian proposed considering both variants of the anyprevout BIP proposal for Eltoo, primarily for the update_tx settlement_tx link. He acknowledged that integrating the chaperone signature would require modifying update transactions. The idea of collapsing 1-of-2 multisigs into a single-sig using a shared private key was suggested. However, taproot's interaction with noinput limits the use of the collaborative path for taproot updates. Bastien emphasized the importance of ensuring Eltoo supports chaperone signatures, even though their necessity is uncertain.Bastien analyzed Anthony Towns' anyprevout BIP proposal and found it beneficial for Eltoo. The separation between anyprevout and anyprevoutanyscript simplifies funding transactions and eliminates the need for a trigger transaction. Integrating the chaperone signature is more challenging, but update transactions could be modified using an OP_IF/OP_ELSE structure. During channel updates, participants would exchange anyprevoutanyscript signatures, and the chaperone signature could be provided by either party at transaction broadcast time. Bastien raised a question about the safety of using the same key for both signatures and highlighted the importance of ensuring Eltoo's compatibility with chaperone signatures in the future.