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 40608A95 for ; Thu, 10 May 2018 14:12:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com [209.85.128.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7CC8D6A5 for ; Thu, 10 May 2018 14:12:37 +0000 (UTC) Received: by mail-wr0-f174.google.com with SMTP id p18-v6so2181816wrm.1 for ; Thu, 10 May 2018 07:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=WjyIH8IX7env16dLG+GZOLE93dZF6La8w1abKfxTaGE=; b=XmAdEptaHW11ARJYVo22NF3qfxlAixlgvZkPtdjjR+DhS9+B3gkmU+r97NrMpPbmiu qGzKvZ/tOuR165sZNP2Tf/v614TxijeJDYmHPg7YSRA+F7+lkdlj19vwa7n8uCg4AxPS 15UyBawv32U0b9PL8b2pnKlUHOkLTVRMmOf5UOn6cERYlKIbpteRFwEM2XTjuKS1XM7v FggMnsu2NIUq9M47kcv1ZdnTU+mJ4yGGHnDVjhEJkkrs1f5N5STPOxMOo8/+CPvsoXhz ixEzHRi1KRXci2SDCrRak8YaFE5xzKgqFKEuuXO95tUHYEGcdMKyuDbT7iNVggpeywSV Efbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=WjyIH8IX7env16dLG+GZOLE93dZF6La8w1abKfxTaGE=; b=rZwP0Ejeg69rDqmy0xfq7Z5yQCfWjHaho0wFO8YKIBVKNY4o4FT+TmD++1JeY75FuG vLZAmm6yQlrFTpN2xPlNUrSIvJPpFw6oPidsGb3tB7fM6nAaj3WDJWy1fxMObjEldEcs zlB4mfjiOT8EWTxxln35F9gYjjndqD2TsT8a775+YybkgbkmfaQ0B3uSEoLMrHgSSXVN KsT3wc+5RXVpv1lcNUPRdE6LuB6v/OkQktUp5WCBVQaLuEqwhybHAtxnsUIT+nSDWXrE sNU0O7tffP/Zvqr1C3OJ8KM3hHh2aApWzF7hyfMEm4tHshzP5Qr0tV62iwuAxxOak9cg yruw== X-Gm-Message-State: ALKqPwfkAAPxrzMs0Yz6xDvZVuS3tlvt6HRZMtzGfWQ3aFad/tLnUMTP 2YCNua3ZeXF5IsrGUUC1XdylIm7k X-Google-Smtp-Source: AB8JxZqDfpsi0657JPEQWOByvQcrbIXOf4KYiU9If6eGkk0Y7AVn2bvxYUEcTjwn5/tvDxnK00Xv6g== X-Received: by 2002:adf:80cd:: with SMTP id 71-v6mr1466702wrl.238.1525961556083; Thu, 10 May 2018 07:12:36 -0700 (PDT) Received: from localhost ([2a02:aa16:1102:5480:e99:3f63:40a2:83e9]) by smtp.gmail.com with ESMTPSA id m134-v6sm1468421wmg.4.2018.05.10.07.12.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 May 2018 07:12:35 -0700 (PDT) From: Christian Decker To: Olaoluwa Osuntokun , Bitcoin Protocol Discussion In-Reply-To: References: <871sewirni.fsf@gmail.com> Date: Thu, 10 May 2018 16:12:21 +0200 Message-ID: <87y3gr38hm.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 Subject: Re: [bitcoin-dev] BIP sighash_noinput 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: Thu, 10 May 2018 14:12:38 -0000 Olaoluwa Osuntokun writes: > Super stoked to see that no_input has been resurrected!!! I actually > implemented a variant back in 2015 when Tadge first described the > approach to me for both btcd [1], and bitcoind [2]. The version being > proposed is _slightly_ differ though, as the initial version I > implemented still committed to the script being sent, while this new > version just relies on witness validity instead. This approach is even > more flexible as the script attached to the output being spent can > change, without rendering the spending transaction invalid as long as > the witness still ratifies a branch in the output's predicate. Yeah, we removed the script commitment out of necessity for eltoo, but it seems to add a lot of flexibility that might be useful. One additional use-case that came to mind is having a recovery transaction for vault-like scenarios, i.e., a transaction that can short-circuit a thawing process of frozen funds. You'd keep that transaction in a vault, pre-signed and bind it to whatever action you'd like to interrupt. > Given that this would introduce a _new_ sighash flag, perhaps we > should also attempt to bundle additional more flexible sighash flags > concurrently as well? This would require a larger overhaul w.r.t to > how sighash flags are interpreted, so in this case, we may need to > introduce a new CHECKSIG operator (lets call it CHECKSIG_X for now), > which would consume an available noop opcode. As a template for more > fine grained sighashing control, I'll refer to jl2012's BIP-0YYY [3] > (particularly the "New nHashType definitions" section). This was > originally proposed in the context of his merklized script work as it > more or less opened up a new opportunity to further modify script > within the context of merklized script executions. The approach reads > in the sighash flags as a bit vector, and allows developers to express > things like: "don't sign the input value, nor the sequence, but sign > the output of this input, and ONLY the script of this output". This > approach is _extremely_ powerful, and one would be able to express the > equivalent of no_input by setting the appropriate bits in the sighash. I purposefully made the proposal as small and as well defined as possible, with a number of possible applications to back it, since I think this might be the best way to introduce a new feature and make it as uncontroversial as possible. I'm not opposed to additional flags being deployed in parallel, but they'll need their own justification and analysis, and shouldn't be rushed just "because we're doing noinput". Going for a separate op-code is definitely an option we considered, but just for noinput it'd be duplicating quite a lot of existing functionality. With additional sighash flags it might become necessary, but I don't think it is necessary just for noinput. > Looking forward in hearing y'alls thoughts on this approach, thanks. > > [1]: https://github.com/Roasbeef/btcd/commits/SIGHASH_NOINPUT > [2]: https://github.com/Roasbeef/bitcoin/commits/SIGHASH_NOINPUT > [3]: https://github.com/jl2012/bips/blob/vault/bip-0YYY.mediawiki#new-nhashtype-definitions > > -- Laolu