diff options
author | Johnson Lau <jl2012@xbt.hk> | 2018-12-14 21:55:43 +0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2018-12-14 13:56:04 +0000 |
commit | 7b6c4122ccea654cad89aa03b4e73330086f835b (patch) | |
tree | ed0c0bd15114099a5a4b5e456170f689b842b4e6 /1f/74a84b4e165eb8d25d01d0d564fb01fe0b83fd | |
parent | 0f50e3af4418be9423e6d383297b3d166ec3849e (diff) | |
download | pi-bitcoindev-7b6c4122ccea654cad89aa03b4e73330086f835b.tar.gz pi-bitcoindev-7b6c4122ccea654cad89aa03b4e73330086f835b.zip |
Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Diffstat (limited to '1f/74a84b4e165eb8d25d01d0d564fb01fe0b83fd')
-rw-r--r-- | 1f/74a84b4e165eb8d25d01d0d564fb01fe0b83fd | 144 |
1 files changed, 144 insertions, 0 deletions
diff --git a/1f/74a84b4e165eb8d25d01d0d564fb01fe0b83fd b/1f/74a84b4e165eb8d25d01d0d564fb01fe0b83fd new file mode 100644 index 000000000..26c57956b --- /dev/null +++ b/1f/74a84b4e165eb8d25d01d0d564fb01fe0b83fd @@ -0,0 +1,144 @@ +Return-Path: <jl2012@xbt.hk> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id AB0C7DC8 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk> +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 <jl2012@xbt.hk> +In-Reply-To: <20181214093002.p2nvfrlaycqblww3@erisian.com.au> +Date: Fri, 14 Dec 2018 21:55:43 +0800 +Content-Transfer-Encoding: quoted-printable +Message-Id: <F9FE2267-0BCB-4C67-9AE8-3285B7459D51@xbt.hk> +References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com> + <87ftv3xerx.fsf@rustcorp.com.au> + <DAAB7568-A004-4897-B5B3-0FBBC6895246@xbt.hk> + <87pnu6s3v5.fsf@rustcorp.com.au> <87h8fiqn1z.fsf@rustcorp.com.au> + <20181214093002.p2nvfrlaycqblww3@erisian.com.au> +To: Anthony Towns <aj@erisian.com.au>, + bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 = +<bitcoin-dev@lists.linuxfoundation.org> 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 +> "<eltoo-channel-id> MASK <statenum> CLTV 2DROP <a+b> 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 + + + |