Reply-To: s7r@sky-ip.org
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
	<CAE-z3OUrM=0XsdfdU2d9h6uhCh9vP83X-OZR8NyAYsvYuE1vtg@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
From: s7r <s7r@sky-ip.org>
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: <CAE-z3OUrM=0XsdfdU2d9h6uhCh9vP83X-OZR8NyAYsvYuE1vtg@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Precedence: list

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
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> 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.
>     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
> 
> 
> 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.
> 
>