summaryrefslogtreecommitdiff
path: root/35/29f80c50e229b72948216db3d843f2ac567891
blob: 9d8f15b99894cb5173e9dbdd3191c06193b0f1e7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id E293990
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 22 Oct 2015 08:57:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com
	[209.85.213.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 88BDB63
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 22 Oct 2015 08:57:30 +0000 (UTC)
Received: by igbhv6 with SMTP id hv6so55519022igb.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 22 Oct 2015 01:57:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type;
	bh=ZnmcIIBpmv0MQgT6jTsfzKg+ySZvBiZhTPK7C9JlI2k=;
	b=oTOT18B9FuFFZYwPiSc/ytcCBhg5NXnzP+Lxx6jbEMbGuqT5H4XTkRoENicZCD+JQH
	4gMOR2tJo0pmk2ewjSo6IDMrSi1N9qk1xYqvQszJqftIxIY1FvBAz1pmfJkECSRyFO3x
	sdyrVwEtU/s2nxRW30Qq6QN29TVhiEg6TIE1nIpRHcjW3YvEqbRE5Y0cdRoYp2BSlUJ2
	JhaB/bqUldqRDTlT/Y4snEEEX78Q2QrLzftmNO+cWxhY5H/qTH9Z1JU4NA+NTQehDSjy
	3vIaxnMX32XuZDhMhB7oixru39T+5MZ8daZ7Ysfu7OoVwfypdxzFX7eQN2eC0AitpJZi
	JVmA==
MIME-Version: 1.0
X-Received: by 10.50.56.71 with SMTP id y7mr2848766igp.48.1445504250000; Thu,
	22 Oct 2015 01:57:30 -0700 (PDT)
Received: by 10.107.23.197 with HTTP; Thu, 22 Oct 2015 01:57:29 -0700 (PDT)
In-Reply-To: <CALxbBHUK_na0qKEBrkCzV2oAUc90wpL4z=7h6Zuu4XzaKEazrA@mail.gmail.com>
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
	<201510210846.43988.luke@dashjr.org>
	<CAJN5wHXSbZPuXN7PQRyOgOMuk2Ogooiww3hW93uNipQJnfkeOg@mail.gmail.com>
	<201510212320.31052.luke@dashjr.org>
	<CALxbBHUK_na0qKEBrkCzV2oAUc90wpL4z=7h6Zuu4XzaKEazrA@mail.gmail.com>
Date: Thu, 22 Oct 2015 08:57:29 +0000
Message-ID: <CAAS2fgTGaonZ=f9LbwYBa7_wnJdfmr-z3_7aTT8d1NewFHGS7g@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
	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
X-Mailman-Approved-At: Thu, 22 Oct 2015 11:27:51 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Oct 2015 08:57:31 -0000

On Thu, Oct 22, 2015 at 8:26 AM, Christian Decker via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Normalized transaction IDs do help in the case that the single signer wants
> to immediately follow up its transaction with another transaction spending
> the first one's change output, and it prevents any modification in the
> multi-signer scenario.

For ordinary transactions which are not performing interesting smart
contracts that particular is better addressed via canonical encoding,
which is immediately available and doesn't have the associated costs
(new pubkey type adoption, 20%-30% UTXO size increase, need for nodes
to fixup txid references, etc.).

Please, as I said up-thread: this is good and importantstuff to work
on, but it shouldn't be oversold.