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 AB0C7DC8 for ; Fri, 14 Dec 2018 13:56:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E882C177 for ; Fri, 14 Dec 2018 13:56:03 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; t=1544795749; cv=none; d=zoho.com; s=zohoarc; b=gFFKJ0v3YSr3wMFKWXbIabPhTlk814Dbx5OKjP+qfapxCqZLo0y26KqbyuzJwzop/hRsvAn/5U1cQyn0O2ioGgw1vdsYaupu9uwj3iefmLWzT8aIyAU7JhkA/+ygy7C2qyaU+ocp9fJiHfKMU+deArGunzQkzAEmdWeZkI5wK/8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1544795749; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results; bh=/Q3+vCDxVgq7Gp4XPC4rf5nX1UIAYD+PRwPnS5PX/hw=; b=QhWC4AXetoWrC+LcYnvcQkjlqhK5jh1jc9K4eJX7go8QOQQrBLa0v7ouvUD/82Ohugnr/1y8uznS1SzkLeZdPVL6YSUPfbgjSds0xA/KKdUGb6/tMqMC/s3hHgbzIhR9CuagyNuMY+iyciamVq00xVC9XcnaLv4yQbYA7w+aakQ= ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk; spf=pass smtp.mailfrom=jl2012@xbt.hk; dmarc=pass header.from= header.from= Received: from [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118]) by mx.zohomail.com with SMTPS id 1544795747619590.9878790388967; Fri, 14 Dec 2018 05:55:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Johnson Lau In-Reply-To: <20181214093002.p2nvfrlaycqblww3@erisian.com.au> Date: Fri, 14 Dec 2018 21:55:43 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87ftv3xerx.fsf@rustcorp.com.au> <87pnu6s3v5.fsf@rustcorp.com.au> <87h8fiqn1z.fsf@rustcorp.com.au> <20181214093002.p2nvfrlaycqblww3@erisian.com.au> To: Anthony Towns , bitcoin-dev X-Mailer: Apple Mail (2.3445.100.39) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 X-Mailman-Approved-At: Mon, 17 Dec 2018 16:09:42 +0000 Subject: Re: [bitcoin-dev] Safer sighashes and more granular 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: Fri, 14 Dec 2018 13:56:04 -0000 I don=E2=80=99t think this has been mentioned: without signing the = script or masked script, OP_CODESEPARATOR becomes unusable or insecure = with NOINPUT. In the new sighash proposal, we will sign the hash of the full script = (or masked script), without any truncation. To make OP_CODESEPARATOR = works like before, we will commit to the position of the last executed = OP_CODESEPARATOR. If NOINPUT doesn=E2=80=99t commit to the masked = script, it will just blindly committing to a random OP_CODESEPARATOR = position, which a wallet couldn=E2=80=99t know what codes are actually = being executed. > On 14 Dec 2018, at 5:30 PM, Anthony Towns via bitcoin-dev = wrote: >=20 > On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via = bitcoin-dev wrote: >> And is it worthwhile doing the mask complexity, rather than just >> removing the commitment to script with NOINPUT? It *feels* safer to >> restrict what scripts we can sign, but is it? >=20 > If it's not safer in practice, we've spent a little extra complexity > committing to a subset of the script in each signature to no gain. If > it is safer in practice, we've prevented people from losing funds. I'm > all for less complexity, but not for that tradeoff. >=20 > Also, saying "I can't see how to break this, so it's probably good > enough, even if other people have a bad feeling about it" is a crypto > anti-pattern, isn't it? >=20 > I don't see how you could feasibly commit to more information than = script > masking does for use cases where you want to be able to spend = different > scripts with the same signature [0]. If that's possible, I'd probably > be for it. >=20 > At the same time, script masking does seem feasible, both for > lightning/eltoo, and even for possibly complex variations of scripts. = So > committing to less doesn't seem wise. >=20 >> You already need both key-reuse and amount-reuse to be exploited. >> SIGHASH_MASK only prevents you from reusing this input for a "normal" >> output; if you used this key for multiple scripts of the same form, >> you're vulnerable[1]. >=20 > For example, script masking seems general enough to prevent footguns > even if (for some reason) key and value reuse across eltoo channels > were a requirement, rather than prohibited: you'd make the script be > " MASK CLTV 2DROP CHECKSIG", and = your > signature will only apply to that channel, even if another channel has > the same capacity and uses the same keys, a and b. >=20 >> So I don't think it's worth it. SIGHASH_NOINPUT is simply dangerous >> with key-reuse, and Don't Do That. >=20 > For my money, "NOINPUT" commits to dangerously little context, and > doesn't really feel safe to include as a primitive -- as evidenced by > the suggestion to add "_UNSAFE" or similar to its name. Personally, = I'm > willing to accept a bit of risk, so that feeling doesn't make me = strongly > against the idea; but it also makes it hard for me to want to support > adding it. To me, committing to a masked script is a huge improvement. >=20 > Heck, if it also makes it easier to do something safer, that's also > probably a win... >=20 > Cheers, > aj >=20 > [0] You could, perhaps, commit to knowing the private keys for all the > *outputs* you're spending to, as well as the inputs, which comes > close to saying "I know this is a scary NOINPUT transaction, but > we're paying to ourselves, so it will all be okay". > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev