rich1.0npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynhttps://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynnjumphttps://nostr.ae📅 Original date posted:2019-10-03 📝 Original message: ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes: > Good morning lists, > > Let me summarize concerns brought up: > > * Chris concern, is that an ordinary UTXO that is not allocated for `SIGHASH_NOINPUT` use, is inadvertently spent using `SIGHASH_NOINPUT`. > * My concern, is that unless a UTXO allocated for `SIGHASH_NOINPUT` use, is *indeed* used with SIGHASH_NOINPUT`, it should look exactly the same as any other SegWit v1 output. > > I propose the below instead: > > * Do ***NOT*** allocate SegWit v16 for `SIGHASH_NOINPUT`. > * Instead, allocate SegWit v1 Tapscript v16 for `SIGHASH_NOINPUT`. > > Then, on usage: > > * Exchange hoards can be protected by simple MuSig bip-schnorr SegWit v1 outputs, or a NUMS Taproot internal point with a MAST branch Tapscript v0 `OP_CHECKSIG_ADD` sequence. > * Decker-Russell-Osuntokun constructions are backed by a n-of-n MuSig Taproot internal point, with a MAST branch containing a Tapscript v16 with `OP_1 OP_CHECKSIG`. > > This solves both concerns: > > * Ordinary UTXOs not allocated for `SIGHASH_NOINPUT` use simply do not commit to any Taproot that has a Tapscript v16 branch, and thus `SIGHASH_NOINPUT` is unuseable to claim it. > * If a UTXO used for an offchain protocol ends up in a cooperative-resolution state, nobody has to know that a Tapscript v16 branch existed that could have used `SIGHASH_NOINPUT`. > > Again, my objection to output tagging is that it is **publicly visible** as soon as the funding transaction is confirmed onchain that this is a special output used for a Decker-Russell-Osuntokun construction, greatly damaging privacy. > But if this fact is kept secret *unless* the very specific case of unilateral uncooperative enforcement, then it is quite fine with me. > > Would this alternate proposal hold better muster? Intriguing idea, this would be an invisible tagging, since the opt-in to noinput and friends is hidden inside the committed script, which only gets revealed whenever we actually need it. For eltoo this would mean that the funding output would be invisibly tagged, and the cooperative close would use the taproot pubkey, while the uncooperative close, which would require noinput opt-in, reveals the script, proving prior opt-in, and provides a matching signature. If I'm not mistaken this would require AJ's alternative pubkey encoding (0x01 or 0x00 prefixed pubkey) to make the opt-in visible, correct?