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 6462A486 for ; Mon, 19 Oct 2015 14:01:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 953B2EB for ; Mon, 19 Oct 2015 14:01:16 +0000 (UTC) Received: by wikq8 with SMTP id q8so7366774wik.1 for ; Mon, 19 Oct 2015 07:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=fR0+sI7IUkPq0YsgTOgLdcinujLtTEQViid9rQ5D4W8=; b=aFLFzfTE0OH0GZ5rvtOgLPqNgCHjt30rp0iHjc3xgxoW5x+UxDfWphXRYucHbMuRp1 uInqUG+TyG8m6YrUV7zRhf/lIJKcQCzZ9FKflYWr/7XyObcFY9kkMp9/jqXY2nSb1S6Y SJ0tomp0E75OKFuyTXk1b4dlcWbvPGDOcrtTlXGYTaraN/P1NXLF7UoKC3NG5qT+vObb csQIifuKHrjPoYF1/wthyVJqNgSJMsJzQqgOp1F9KiznQA2BNPBoXtDzXmN0qf7g1iq0 9W9aPhC6h1dTtkiMFlFnNN2qjLoTBW+TK179Ub8GGFbEcrmjARy01YgIwglGHvhLQ4qG RwBQ== X-Received: by 10.194.239.230 with SMTP id vv6mr32423761wjc.21.1445263274303; Mon, 19 Oct 2015 07:01:14 -0700 (PDT) MIME-Version: 1.0 From: Christian Decker Date: Mon, 19 Oct 2015 14:01:04 +0000 Message-ID: To: Bitcoin development mailing list Content-Type: multipart/alternative; boundary=089e0141a3d6127fd7052275940a X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW 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] [BIP] Normalized transaction IDs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 14:01:17 -0000 --089e0141a3d6127fd7052275940a Content-Type: text/plain; charset=UTF-8 After spending some more time on the normalized transaction ID proposal and reworking it to be a soft-fork (thanks sipa for helping me figuring out how), I'd like to propose the BIP again. As with the previous version, which was using a hard-fork, the normalized transaction ID is computed only considering the non-malleable parts of a transaction, i.e., stripping the signatures before computing the hash of the transaction. This ensures that if a transaction is modified, either by a third party fishing transactions from the network and re-injecting modified versions or by one of the signers re-signing it, any transaction that builds on top of it still remains valid. Furthermore it allows the use of template transactions, unsigned transactions upon which further transaction can be built before signing the template transaction and locking the contract. Unlike the previous proposal, this is a softfork proposal that redefines OP_NOP4 with an extensible and parameterized version of the signature checking opcodes, called OP_CHECKSIGEX. Among other things the parameters allow to specify that an output with an OP_CHECKSIGEX is to be referenced by the normalized transaction ID that created it, instead of the instance transaction ID containing malleable signatures. This BIP uses the normalized transaction IDs exclusively while signing or checking signatures, they are not used in any network level message as the previous version would have done, hence there is no change at network level and old clients should be able to exchange transactions as before and blocks still reference the transaction instances. The proposal is implemented (see below), by computing the normalized transaction ID when adding them to the UTXO and storing them along with the coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into how to best refactor the common functionality into reusable blocks. And the annotating incoming transactions with their normalized inputs is a bit cumbersome, maye somebody has some pointers here as well? BIP Pull request: https://github.com/bitcoin/bips/pull/224 Implementation: https://github.com/cdecker/bitcoin/commits/normtx I think in the discussion of my previous proposal, most of you welcomed the introduction of normalized transaction IDs, were it not for the hardfork. I hope this proposal adresses the previous concerns and that we can move forward in adding the normalized transaction IDs to the bitcoin protocol. That being said, I'm always open to suggestions :-) Regards, Christian --089e0141a3d6127fd7052275940a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After spending some more time on the normalized transactio= n ID proposal and reworking it to be a soft-fork (thanks sipa for helping m= e figuring out how), I'd like to propose the BIP again.

<= div>As with the previous version, which was using a hard-fork, the normaliz= ed transaction ID is computed only considering the non-malleable parts of a= transaction, i.e., stripping the signatures before computing the hash of t= he transaction. This ensures that if a transaction is modified, either by a= third party fishing transactions from the network and re-injecting modifie= d versions or by one of the signers re-signing it, any transaction that bui= lds on top of it still remains valid. Furthermore it allows the use of temp= late transactions, unsigned transactions upon which further transaction can= be built before signing the template transaction and locking the contract.=

Unlike the previous proposal, this is a softfork = proposal that redefines OP_NOP4 with an extensible and parameterized versio= n of the signature checking opcodes, called OP_CHECKSIGEX. Among other thin= gs the parameters allow to specify that an output with an OP_CHECKSIGEX is = to be referenced by the normalized transaction ID that created it, instead = of the instance transaction ID containing malleable signatures. This BIP us= es the normalized transaction IDs exclusively while signing or checking sig= natures, they are not used in any network level message as the previous ver= sion would have done, hence there is no change at network level and old cli= ents should be able to exchange transactions as before and blocks still ref= erence the transaction instances.

The proposal is = implemented (see below), by computing the normalized transaction ID when ad= ding them to the UTXO and storing them along with the coin state. OP_CHECKS= IGEX mostly duplicates OP_CHECKSIG and OP_CHECKMULTISIG, but I'm hoping= somebody can give me some pointers into how to best refactor the common fu= nctionality into reusable blocks. And the annotating incoming transactions = with their normalized inputs is a bit cumbersome, maye somebody has some po= inters here as well?


I think in the discussion of my previous = proposal, most of you welcomed the introduction of normalized transaction I= Ds, were it not for the hardfork. I hope this proposal adresses the previou= s concerns and that we can move forward in adding the normalized transactio= n IDs to the bitcoin protocol. That being said, I'm always open to sugg= estions :-)

Regards,
Christian
--089e0141a3d6127fd7052275940a--