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 D33618A6 for ; Wed, 28 Jun 2017 07:01:42 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 26BF71CE for ; Wed, 28 Jun 2017 07:01:42 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1dQ6yo-00049F-LY for ; Wed, 28 Jun 2017 17:01:40 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Wed, 28 Jun 2017 17:01:33 +1000 Date: Wed, 28 Jun 2017 17:01:33 +1000 From: Anthony Towns To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20170628070133.GA2421@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Replay protection via CHECKSIG 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: Wed, 28 Jun 2017 07:01:42 -0000 Hi, I thought of a possibly interesting way to prevent transaction replay in the event of a chain split, that seems better to the other approaches I've seen. Basically, update OP_CHECKSIG (and MULTISIG and the VERIFY variants, presumably via segwit versioning or using a NOP opcode) so that signatures can optionally specify an additional integer block-height. If this is provided, the message hash is combined with the block hash at the given height, before the signature is created/verified, and therefore the signature becomes invalid if used on a chain that does not have that particular block in its history [0]. It adds four bytes to a signature that uses the feature [1], along with a block hash lookup, and some extra sha ops when verifying the signature, but it otherwise seems pretty lightweight, and scales to an arbitrary number of forks including a pretty fair range of hard forks, as far as I can see, without requiring any coordination between any of the chains. So I think it's superior to what Johnson Lau proposed in January [2] or BIP 115 from last year [3]. Thoughts? Has this been proposed before and found wanting already? Cheers, aj [0] For consistency, you could use the genesis block hash if the signature doesn't specify a block height, which would lock a given signature to "bitcoin" or "testnet" or "litecoin", which might be beneficial. [1] Conceivably a little less if you allow "-5" to mean "5 blocks ago" and miners replace a four byte absolute reference ("473000") with a one or two byte relative reference ("-206") when grabbing transactions from the mempool to put in the block template. [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013473.html [3] https://github.com/bitcoin/bips/blob/master/bip-0115.mediawiki