Author: Bryan Bishop 2020-02-09 20:24:32
Published on: 2020-02-09T20:24:32+00:00
This email is the third of a collection of sentiments from a group of developers who prefer to remain anonymous. These emails have been sent under a pseudonym so as to keep the focus of discussion on the merits of the technical issues, rather than miring the discussion in personal politics. The goal of the group isn't to cause a schism but to help figure out what the path forward is with Taproot.To that end, the group discusses the merits of Taproot's design versus simpler alternatives, proposes an alternative path to deploying the technologies described in BIP-340, BIP-341, and BIP-342, and suggests a modification to Taproot to reduce some of the overhead.The group proposes to modify Taproot's specification in BIP-341 by adding the rule: If there is one element on the witness stack, attempt hashing it to see if it's equal to the witness program. If it's not the witness program, and it's 65 bytes, try signature validation. If there is more than one element on the witness stack, treat it as a non-Taproot MAST and get the leaf version as the last byte of the script.If greater anonymity is required, a NUMS point can still be used in Taproot, at the expense of the additional data. However, if NUMS points are just a couple of well-known constants, this could actually decrease privacy as then the NUMS points could differ from application to application fingerprinting wallets. Instead, the NUMS point should only be used when a single-use nonce can be sent, so that NUMS cannot be distinguished from a normal Taproot to a third party who doesn't know the setup (e.g., that the NUMS is H(X) for known X).
Updated on: 2023-06-13T23:32:06.110926+00:00