summaryrefslogtreecommitdiff
path: root/1f/74a84b4e165eb8d25d01d0d564fb01fe0b83fd
diff options
context:
space:
mode:
authorJohnson Lau <jl2012@xbt.hk>2018-12-14 21:55:43 +0800
committerbitcoindev <bitcoindev@gnusha.org>2018-12-14 13:56:04 +0000
commit7b6c4122ccea654cad89aa03b4e73330086f835b (patch)
treeed0c0bd15114099a5a4b5e456170f689b842b4e6 /1f/74a84b4e165eb8d25d01d0d564fb01fe0b83fd
parent0f50e3af4418be9423e6d383297b3d166ec3849e (diff)
downloadpi-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/74a84b4e165eb8d25d01d0d564fb01fe0b83fd144
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
+
+
+