Published on: 2020-03-16T07:31:44+00:00
The email conversation and discussions revolve around the security of Taproot and how it can be formally modeled. The author suggests that a commitment scheme is a more natural model for Taproot's security, but an optimal model should capture both worlds. The properties of this model include that obtaining signatures for the inner key does not help to forge the outer key, obtaining signatures for the outer key does not help to open the commitment, and obtaining an opening does not help to forge either key.The author hopes to prove that any secure key generation method will be secure once Taproot is applied if it is a secure commitment scheme. They believe that we can dismiss the need for any signing or commitment opening oracles in any security notion of Taproot and restrict our notion of Taproot's security to its interaction with the key generation protocol only. This leads to a modular and composable security model for Taproot.In a conversation between Lloyd Fournier and Tim Ruffing, Lloyd provides comments on the security of Taproot. Property (2) is difficult to argue as it depends on the multi-party key generation protocol. Taproot is completely broken when combined with a proof of knowledge key generation protocol where each party provides a proof of knowledge of the secret key. Poelstra presented a proof in the ROM for the security of Taproot. It frames Taproot as a way of combining two signature schemes into one public key - Schnorr and Tapscript. Modeling it as a commitment scheme is more natural, but an optimal model would capture both worlds.The discussion further revolves around the use of an interactive key generation protocol similar to coin tossing, which generates a uniformly random key. This is compared to MuSig, which is not guaranteed to be uniformly random against a malicious party. The coordination and interaction required to arrange getting into an n-of-n is also discussed, as well as reducing latency by reducing communication rounds. Different counters and plans are proposed to address these issues.In another email conversation, LL is thanked by ZmnSCPxj for a work that seems quite interesting. ZmnSCPxj asks for clarification about "coin-tossing" as it was mentioned in the previous message. LL explains that coin-tossing is an interactive key generation protocol where everyone generates fresh keypairs and sends the hash of their pubkey to everyone else. After receiving hashes from everyone else, everybody sends their pubkeys to generate the aggregate key. The benefits and drawbacks of reducing communication rounds for creating signatures during offchain operation are also discussed.The Financial Cryptography conference 2020 featured a poster presentation by LLFourn that aimed to demonstrate the security requirements for the tweak hash function in Taproot. The author explained that Taproot requires no new assumptions of SHA256 over what are already made by Schnorr signatures themselves, except when using a non-interactive key generation protocol to produce a Taproot internal key. The poster used the Generic Group Model to figure out how the hash function would have to fail for Taproot to be insecure. There are three scenarios/games to consider when asking whether Taproot is secure in the context of Bitcoin: Taproot Forge, Covert Taproot, and Second Covert Taproot.Properties (1) and (2) can be argued succinctly if we prove that Taproot is a secure commitment scheme. Property (2) is more difficult to argue as it depends on the multi-party key generation protocol. The MuSig key generation protocol is considered in this case. Proving that Taproot is a binding commitment scheme in the Random Oracle Model is straightforward and proves properties (1) and (3). For property (2), the reduction does not work for n-party MuSig.The cost of Taproot is mostly borne by theoreticians as they have to consider the implications of it being both a public key and a commitment. However, for the user and Bitcoin as a whole, it offers an overwhelming benefit. It adds complexity to making security claims in the GGM but also offers exciting new opportunities for non-interactivity and fungibility over what just Schnorr would provide. The work presented is not considered a final proof, and anyone who wants to take over this research direction and do a proper job of it is welcome to do so.
Updated on: 2023-08-02T01:54:55.985605+00:00