Re: [bitcoin-dev] [BIP] Normalized transaction IDs

From: Christian Decker <decker.christian@gmail•com>
To: s7r@sky-ip•org, bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Date: Tue, 20 Oct 2015 10:30:33 +0000	[thread overview]
Message-ID: <CALxbBHVcorvyQnwkDw6O-s6_4uozOY2BB3Aj12H9re2xfyaomA@mail.gmail.com> (raw)
In-Reply-To: <56256D36.5050801@sky-ip.org>

[-- Attachment #1: Type: text/plain, Size: 3541 bytes --]

On Tue, Oct 20, 2015 at 12:23 AM s7r via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> 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?
>

The normalization involves two steps:
 - strip the scriptSig scripts in the inputs, i.e., the only part whose
integrity is not guaranteed by the signature itself, by replacing the
scripts with empty strings (var length string of size 0)
 - replace the hashes referencing the outputs being spent with the
normalized hashes of the transaction that created the outputs. This is done
recursively down to the first v2 transactions.

The second part is not yet explained in the draft, but I will amend it as
soon as possible.

> 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.
>

Non-coinbase transactions can still not be replayed since the normalized
transaction still includes a the normalized transaction hashes of claimed
outputs, hence any attempt to replay a transaction would fail since the
outputs were already spent. For coinbase transactions it is indeed possible
that we create multiple transactions with the same hash (only one of which
would be spendable), hence we do not strip coinbase transactions and rely
on BIP 34 to make the coinbase transactions unique (except for blocks 91842
and 91880 which are the reason we introduced BIP 34 in the first place).
Clarifying the way the normalized transaction ID is computed should remove
any ambiguities I hope.

>
> 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)?
>

Yes, if the computation of the normalized transaction ID includes replacing
input hashes with their normalized counterpart makes a chain of any depth
non-malleable.

HTH,
Christian

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

[-- Attachment #2: Type: text/html, Size: 5059 bytes --]