Here seeking information. I have 4 questions marked with parens
Would like some clarification pertaining to the Mark Friedenbach article:
The point of contention with Mark seems to be the idea of the space savings for the N-N Musig2 everyone signs/happy path being embedded into the the root of the MAST/Taproot?
(1) please correct if I’m wrong about the way I’m describing this.
I did see Pieter’s presentation at Bitdevs from a while back reference, “plain pubkey security model in mind” for taproot. But, it wasn’t apparent that this would hypothetically make it quantum vulnerable,.. as Mark’s article says, “a naked secp256k1 pubkey on chain at the time the output is created which has absolute spend authority for the underlying bitcoins”.
(2) Would love for someone to rebut or verify this claim.
From what I’ve gathered.. Taproot is a combination of Schnorr, MAST, Musig, etc.. but the exact, small piece of all of this, which is “Taproot”, is explained by 3 fellows as:
- Greg, “a special delegating CHECKSIG which I call Taproot.”
- Poelstra, “trick to hide a commitment inside a pubkey”
- Pieter, “pay to a script pubkey of taproot EC point P.”
(3) Are these accurate concise snippets for the crux of Taproot, which is we don’t need a separate branch for the N-N everyone agrees spend?
(4) Also, is
OP_CHECKSIGADD the now realized “CHECKSIG” greg mentions in the O.G. taproot post