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 5164C409 for ; Mon, 19 Oct 2015 22:22:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outbound.mailhostbox.com (outbound.mailhostbox.com [162.222.225.14]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 99742137 for ; Mon, 19 Oct 2015 22:22:50 +0000 (UTC) Received: from [0.0.0.0] (exit-tor.tykva.info [209.133.66.214]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: s7r@sky-ip.org) by outbound.mailhostbox.com (Postfix) with ESMTPSA id 13F6B1A1B3A for ; Mon, 19 Oct 2015 22:22:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky-ip.org; s=20110108; t=1445293369; bh=a5F4vs6XiDxBx7RYzxCg5PmCZdSxcIwKToi//xHXAL0=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=c0Pm42MLK2apmQlGa804Nrgjd7vxldDa930qAV4eVHANHw+Y5FO5R6UYYyHBv9Y/V Nxg/IiiAIAwQ2kzA2SjRoJVIqGcDKnEUO6a+lBoCZRhOhPze7n1kpiQjulF9QXfpSY dyvOc6RWtdIisqyYCDs5Tc6yrRYXt3hyXq95Hx+Q= Reply-To: s7r@sky-ip.org References: To: bitcoin-dev@lists.linuxfoundation.org From: s7r X-Enigmail-Draft-Status: N1010 Message-ID: <56256D36.5050801@sky-ip.org> Date: Tue, 20 Oct 2015 01:22:46 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-CMAE-Score: 0 X-CMAE-Analysis: v=2.1 cv=IPz/cVbG c=1 sm=1 tr=0 a=QVMj3kqrJ5NkcnqZZZ66eQ==:117 a=QVMj3kqrJ5NkcnqZZZ66eQ==:17 a=N659UExz7-8A:10 a=QPuc3nO-0ARW_2InZ1EA:9 a=pILNOxqGKmIA:10 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.92 X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,URIBL_BLACK autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [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 22:22:58 -0000 So what exactly is used to create the normalized txid (sha256 hash of what data)? I've read in the linked BIP draft that it will strip the 'malleable parts' but didn't understand what exactly will be used to calculate the normalized transactions ids and how will the change apply retro-active for the transactions so deep buried in the blockchain? Pubkeys (addresses) can be reused infinitely so what guarantees us unique normalized txids all the time and protection against replay attacks? The question is not if this issue is covered or not, I know it is, I am just asking how, in simpler terms. SCRIPT_CHECKSIGEX_NORMALIZE could be explained better in the document. Will it also fix > third level malleability (a tx which spends from another unconfirmed tx which spends from yet another unconfirmed tx)? On 10/19/2015 6:23 PM, Tier Nolan via bitcoin-dev wrote: > On Mon, Oct 19, 2015 at 3:01 PM, Christian Decker via bitcoin-dev > > wrote: > > 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. > > > > Is this proposal recursive? > > *Coinbase transaction > * > > * n-txid = txid > > *Non-coinbase transactions > * > * replace sigScripts with empty strings > * replace txids in TxIns with n-txid for parents > > The 2nd step is recursive starting from the coinbases. > > In effect, the rule is that txids are what they would have been if > n-txids had been used right from the start. > >