Author: Andrew Poelstra 2023-07-26 17:40:26+00:00
Published on: 2023-07-26T17:40:26+00:00
POSK is not a panacea and has limitations. In MuSig, using POSK to eliminate rogue key attacks instead of rerandomizing the keys can lead to issues. The last person contributing a key could modify the final key by adding a Taproot commitment without the knowledge of other participants. This creates a Taproot spending path that others are unaware of. Producing POSKs in many contexts is logistically difficult as it requires an interactive challenge-response, meaning all participants must be online with secret key access during key setup. Static POSKs may be sufficient in some cases but there is no established key serialization format that includes them. If already-published keys do not have a POSK attached, they cannot be used. Publishing POSKs also presents difficulties as they cannot be embedded on-chain and require an alternative publication medium. Supporting nested multisignatures requires jointly producing POSKs, adding to protocol complexity. The MuSig and MuSig2 papers address these challenges by developing a scheme that is provably secure in the plain public key model, rendering POSKs unnecessary.
Updated on: 2023-08-11T15:36:06.177621+00:00