From ZmnSCPxj at protonmail.com Mon Sep 30 23:28:43 2019 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 30 Sep 2019 23:28:43 +0000 Subject: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout In-Reply-To: <-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com> References: <87wodp7w9f.fsf@gmail.com> <-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com> Message-ID: Good morning list, To elucidate further --- Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, `OP_CHECKSIG_WITHOUT_INPUT`. This new opcode ignores any `SIGHASH` flags, if present, on a signature, but instead hashes the current transaction without the input references, then checks that hash to the signature. This is equivalent to `SIGHASH_NOINPUT`. Yet as an opcode, it would be possible to embed in a Taproot script. For example, a Decker-Russell-Osuntokun would have an internal Taproot point be a 2-of-2, then have a script `OP_1 OP_CHECKSIG_WITHOUT_INPUT`. Unilateral closes would expose the hidden script, but cooperative closes would use the 2-of-2 directly. Of note, is that any special SCRIPT would already be supportable by Taproot. This includes SCRIPTs that may potentially lose funds for the user. Yet such SCRIPTs are already targetable by a Taproot address. If we are so concerned about `SIGHASH_NOINPUT` abuse, why are we not so concerned about Taproot abuse? Regards, ZmnSCPxj