Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.45 as permitted sender)
	client-ip=209.85.192.45;
	envelope-from=stephencalebmorse@gmail.com;
	helo=mail-qg0-f45.google.com; 
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Stephen <stephencalebmorse@gmail.com>
In-Reply-To: <5555C26F.7080706@sky-ip.org>
Date: Fri, 15 May 2015 23:58:56 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC0B3BAC-0934-46A3-B29A-F74238616F72@gmail.com>
References: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
	<5555C26F.7080706@sky-ip.org>
To: "s7r@sky-ip.org" <s7r@sky-ip.org>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
Precedence: list

We should make sure to consider how BIP34 affects normalized transaction ids=
, since the height of the block is included in the scriptSig ensuring that t=
he txid will be different. We wouldn't want to enable replay attacks in the f=
orm of spending coinbase outputs in the same way they were spent from a prev=
ious block.=20

So maybe normalized txids should strip the scriptSigs of all transactions ex=
cept for coinbase transactions? This seems to make sense, since coinbase tra=
nsactions are inherently not malleable anyway.=20

Also, s7r linked to my 'Build your own nHashType' proposal (although V2 is h=
ere: https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal_v2=
.md). I just wanted to add that I think even with normalized ids, it could s=
till be useful to be able to apply these flags to choose which parts of the t=
ransaction become signed. I've also seen vague references to some kind of a m=
erklized abstract syntax tree, but am not fully sure how that would work. Ma=
ybe someone on here could explain it?=20

Best,
Stephen


> On May 15, 2015, at 5:54 AM, s7r <s7r@sky-ip.org> wrote:
>=20
> Hello,
>=20
> How will this exactly be safe against:
> a) the malleability of the parent tx (2nd level malleability)
> b) replays
>=20
> If you strip just the scriptSig of the input(s), the txid(s) can still
> be mutated (with higher probability before it gets confirmed).
>=20
> If you strip both the scriptSig of the parent and the txid, nothing can
> any longer be mutated but this is not safe against replays. This could
> work if we were using only one scriptPubKey per tx. But this is not
> enforced, and I don't think it's the proper way to do it.
>=20
> Something similar can be achieved if you would use a combination of
> flags from here:
>=20
> https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
>=20
> But this has some issues too.
>=20
> I've read your draft but didn't understand how exactly will this prevent
> normal malleability as we know it, second level malleability and replays
> as well as how will we do the transition into mapping the txes in the
> blockchain to normalized txids. Looking forward to read more on this
> topic. Thanks for the brainstorming ;)
>=20
>=20
>> On 5/13/2015 3:48 PM, Christian Decker wrote:
>> Hi All,
>>=20
>> I'd like to propose a BIP to normalize transaction IDs in order to
>> address transaction malleability and facilitate higher level protocols.
>>=20
>> The normalized transaction ID is an alias used in parallel to the
>> current (legacy) transaction IDs to address outputs in transactions. It
>> is calculated by removing (zeroing) the scriptSig before computing the
>> hash, which ensures that only data whose integrity is also guaranteed by
>> the signatures influences the hash. Thus if anything causes the
>> normalized ID to change it automatically invalidates the signature. When
>> validating a client supporting this BIP would use both the normalized tx
>> ID as well as the legacy tx ID when validating transactions.
>>=20
>> The detailed writeup can be found
>> here: https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.media=
wiki.
>>=20
>> @gmaxwell: I'd like to request a BIP number, unless there is something
>> really wrong with the proposal.
>>=20
>> In addition to being a simple alternative that solves transaction
>> malleability it also hugely simplifies higher level protocols. We can
>> now use template transactions upon which sequences of transactions can
>> be built before signing them.
>>=20
>> I hesitated quite a while to propose it since it does require a hardfork
>> (old clients would not find the prevTx identified by the normalized
>> transaction ID and deem the spending transaction invalid), but it seems
>> that hardforks are no longer the dreaded boogeyman nobody talks about.
>> I left out the details of how the hardfork is to be done, as it does not
>> really matter and we may have a good mechanism to apply a bunch of
>> hardforks concurrently in the future.
>>=20
>> I'm sure it'll take time to implement and upgrade, but I think it would
>> be a nice addition to the functionality and would solve a long standing
>> problem :-)
>>=20
>> Please let me know what you think, the proposal is definitely not set in
>> stone at this point and I'm sure we can improve it further.
>>=20
>> Regards,
>> Christian
>>=20
>>=20
>> -------------------------------------------------------------------------=
-----
>> One dashboard for servers and applications across Physical-Virtual-Cloud=20=

>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>>=20
>>=20
>>=20
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
> --------------------------------------------------------------------------=
----
> One dashboard for servers and applications across Physical-Virtual-Cloud=20=

> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development