From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DBBBA157B; Tue, 1 Oct 2019 14:27:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 415EE189; Tue, 1 Oct 2019 14:27:46 +0000 (UTC) Received: by mail-ed1-f44.google.com with SMTP id l21so12103842edr.5; Tue, 01 Oct 2019 07:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=hzVotQYitl00VcN8MS99CdnasZQLSUMuEueHu2I/q5Y=; b=BStIt7nhoAaRD0AfmdlZT9Wnd+OgVEwSHbdPUFlwu+sBXeoZqKWeTNbrWZPxqSg2x7 BdLvNDwWJs39bMkotVm4Tz5e0YvZBzO6RElVgtWlaKOVmfox9WJZPIxnZGQ6JUUCYYle u0lQkfj82sZc5cRkFQGscKfFBRBGuMN4YRtwi5nQpmCdIx8DwbOMqg6d2FkNZiIaHDVU 9Anvol+A40QzarbTl5jz5wx5RD2ravjaSDOR8byEQVRdWewTBmXzI3MgVSj6SL/vk2Ls SERr/2l4M8o1vzt9n05bRjLc6cFODE5tHBHtWa5PJkgk6H3VhidjAi9rPAutOX4QwUCo 5jKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=hzVotQYitl00VcN8MS99CdnasZQLSUMuEueHu2I/q5Y=; b=oprKkhLHihtkLJiQsp5lKypf+muVJ3dan9/JGpzgioAZdNbx9gtwU1YXy1NvdzljUi pxu4k2WMIBU3cZUDrvKEWZC1WOVxb9H8tNEiR7eRMbhLM8W+ukozsMbLxH0qc6vsFiOa RK2zfDK2whLoXwfRrR80ZQbKHO+cgIDT8yYwphzGvcHNjOFs4gRSUxoy2DKCe1lN/D3+ AsfVOT66YK6Iwp8bFrNpS+n+58hmXVyY/86BqICYNhuegFrf6frse2oPpyegXFa9H4rX mqLTI+xAzhD+/fHvVrOlINFnKvtLH6QSrDC6CBWmmzgkpgScYsqBAD2b9AoNAdbKAsMj Y0Aw== X-Gm-Message-State: APjAAAUUjPrHiYZPSDy6ykRsq/OKDmrRnsrIXyIbW2QTVxaKCVI7liGI nosJ9M05UdP7zCOB1Lr5xM18lcIsd7o= X-Google-Smtp-Source: APXvYqw68nwO0oNUfLIkmkLvhRIFJPPFBOmUQQFnT86Nbuasff7EUu2+5Aa2ksUX2dRFSqGjQHbYig== X-Received: by 2002:a17:906:5fc4:: with SMTP id k4mr24759719ejv.300.1569940064834; Tue, 01 Oct 2019 07:27:44 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:dde:e0b1:d1a1:c9fa]) by smtp.gmail.com with ESMTPSA id u30sm3138638edd.18.2019.10.01.07.27.44 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 01 Oct 2019 07:27:44 -0700 (PDT) From: Christian Decker To: ZmnSCPxj , ZmnSCPxj , Bitcoin Protocol Discussion In-Reply-To: References: <87wodp7w9f.fsf@gmail.com> <-5H29F71ID9UFqUGMaegQxPjKZSrF1mvdgfaaYtt_lwI7l1OTmN_8OgcooyoMt2_XuyZ5aDljL6gEup9C7skF8iuP_NbMW_81h0tJIGbJno=@protonmail.com> Date: Tue, 01 Oct 2019 16:26:39 +0200 Message-ID: <87r23w7d9c.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: "lightning-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 14:27:47 -0000 ZmnSCPxj writes: > 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? That would certainly be another possibility, which I have not explored in detail so far. Due to the similarity between the various signature checking op-codes it felt that it should be a sighash flag, and it neatly slotted into the already existing flags. If we go for a separate opcode we might end up reinventing the wheel, and to be honest I feared that proposing a new opcode would get us into bikeshedding territory (which I apparently failed to avoid with the sighash flag anyway...). The advantage would be that with the sighash flag the spender is in charge of specifying the flags, whereas with an opcode the output dictates the signature verification modalities. The downside is the increased design space. What do others think? Would this be an acceptable opt-in mechanism that addresses the main concerns? Cheers, Christian