Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CD588305 for ; Tue, 20 Oct 2015 10:30:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EB662A6 for ; Tue, 20 Oct 2015 10:30:45 +0000 (UTC) Received: by wijp11 with SMTP id p11so40155987wij.0 for ; Tue, 20 Oct 2015 03:30:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=f5gC7tXZB2/KLQd83cH47e1izBJa9QHCI2/l0n6ZbQk=; b=bQSwtQwKnA62eMkQjio1DophY4ObKCNzFfatxARcVrI1gyv097C0m/h1KT4mprONbW r4VRLd5Tjqvpgmu+2erdwFd5wolEINVv9uJySjdz06sO5w2otv8m+uS6P+JA11NTJ1/k kiVqWOC+/CZA+MR2WpD8YcMcKI74XHGbufymD7NkhASOpLru9m0sXeVY2TOUbx71MbVM HICpaJmiYNAo0mGZevGEa5I5NRpvObbRqgM1W4u9/IcOd5Iu8NoLV8UAzbHVhb4szIAs KJLSocjynPXIq/nh8UMtPOWvIGdcdx3MgUSEGEKXddGZVSxVhuIGf9t5X3dJ4asHVfxG KIDQ== X-Received: by 10.194.239.230 with SMTP id vv6mr3180334wjc.21.1445337044104; Tue, 20 Oct 2015 03:30:44 -0700 (PDT) MIME-Version: 1.0 References: <56256D36.5050801@sky-ip.org> In-Reply-To: <56256D36.5050801@sky-ip.org> From: Christian Decker Date: Tue, 20 Oct 2015 10:30:33 +0000 Message-ID: To: s7r@sky-ip.org, bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=089e0141a3d6183c77052286c13b 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: 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: Tue, 20 Oct 2015 10:30:46 -0000 --089e0141a3d6183c77052286c13b Content-Type: text/plain; charset=UTF-8 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 > > > > 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. > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --089e0141a3d6183c77052286c13b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 20= , 2015 at 12:23 AM s7r via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrot= e:
So what exactly is used to creat= e 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 us= ed 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:
=C2=A0- strip the scriptSig scripts in the inputs, i.e., the only part wh= ose integrity is not guaranteed by the signature itself, by replacing the s= cripts with empty strings (var length string of size 0)
=C2=A0- r= eplace the hashes referencing the outputs being spent with the normalized h= ashes of the transaction that created the outputs. This is done recursively= down to the first v2 transactions.

The second par= t is not yet explained in the draft, but I will amend it as soon as possibl= e.


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 normaliz= ed transaction still includes a the normalized transaction hashes of claime= d outputs, hence any attempt to replay a transaction would fail since the o= utputs 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 o= n 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). Cl= arifying the way the normalized transaction ID is computed should remove an= y ambiguities I hope.
=C2=A0

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 tr= ansaction ID includes replacing input hashes with their normalized counterp= art makes a chain of any depth non-malleable.

HTH,=
Christian=C2=A0


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: >
>=C2=A0 =C2=A0 =C2=A0As with the previous version, which was using a har= d-fork, the
>=C2=A0 =C2=A0 =C2=A0normalized transaction ID is computed only consider= ing the
>=C2=A0 =C2=A0 =C2=A0non-malleable parts of a transaction, i.e., strippi= ng the signatures
>=C2=A0 =C2=A0 =C2=A0before computing the hash of the transaction.
>=C2=A0 =C2=A0 =C2=A0<https://li= sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
> Is this proposal recursive?
>
> *Coinbase transaction
> *
>
> * n-txid =3D 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/mail= man/listinfo/bitcoin-dev
--089e0141a3d6183c77052286c13b--