path: root/d1/2612bc2fe0fe70b429c09c255c65556b09c738

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <stephencalebmorse@gmail.com>) id 1YtTFj-0005wF-CH
	for bitcoin-development@lists.sourceforge.net;
	Sat, 16 May 2015 03:59:07 +0000
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; 
Received: from mail-qg0-f45.google.com ([209.85.192.45])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YtTFf-000828-Ag
	for bitcoin-development@lists.sourceforge.net;
	Sat, 16 May 2015 03:59:07 +0000
Received: by qgew3 with SMTP id w3so19937851qge.2
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 15 May 2015 20:58:58 -0700 (PDT)
X-Received: by 10.140.32.38 with SMTP id g35mr11406491qgg.74.1431748737909;
	Fri, 15 May 2015 20:58:57 -0700 (PDT)
Received: from [192.168.0.4] (cpe-108-176-225-232.maine.res.rr.com.
	[108.176.225.232])
	by mx.google.com with ESMTPSA id q74sm2436648qha.4.2015.05.15.20.58.57
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Fri, 15 May 2015 20:58:57 -0700 (PDT)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Stephen <stephencalebmorse@gmail.com>
X-Mailer: iPhone Mail (12F70)
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>
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(stephencalebmorse[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YtTFf-000828-Ag
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 16 May 2015 03:59:07 -0000

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