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
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id ED9733EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Oct 2015 11:54:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com
[209.85.212.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 37A8AA9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Oct 2015 11:54:28 +0000 (UTC)
Received: by wijp11 with SMTP id p11so28100340wij.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Oct 2015 04:54:26 -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
:cc:content-type;
bh=YVW3ggXwGNi73WJZBQaYmpzCBkC1KmX6j8zjNlW1Ta8=;
b=q9+7dba+KpMX0lfrtv8e2ieBBjQ4J5+ZJVgmCSCvmgK4bF5Itr3xCUurU+G/Ztn5NM
072nX0WRAFACkjpCckS57yWLVI1V67yigmCa+qJkhJY8I3hReC0LttGmkfUa1Zwh8Hj5
MOWTSLRL45ZiZsxyKtPyr+2mID4BTYRgbCWYJJ1I70pU9nIpu0lsX+PdNMXGQ0EagRzr
7BXiz9HwyzxN5ZslHZ6CUNeg3WuS9aM+/LoObBHqnBM1FNGyiiwQCSk3EzGzeLWh/2gZ
RgYHwR7pZ2hwSRsu4eiOOhsQWGrfl1rvTPrMDTqvXjYuwk/WIqmjsg2fBruqmOthvr1L
LEdw==
X-Received: by 10.194.11.71 with SMTP id o7mr16920452wjb.75.1445514866733;
Thu, 22 Oct 2015 04:54:26 -0700 (PDT)
MIME-Version: 1.0
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>
<CAAS2fgTGaonZ=f9LbwYBa7_wnJdfmr-z3_7aTT8d1NewFHGS7g@mail.gmail.com>
In-Reply-To: <CAAS2fgTGaonZ=f9LbwYBa7_wnJdfmr-z3_7aTT8d1NewFHGS7g@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Thu, 22 Oct 2015 11:54:17 +0000
Message-ID: <CALxbBHWaQ=_w0F=LkJHDxUB6QVM8MpH_Y-n2U3eowxYVpdBmQA@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b4508de264bbc0522b0288e
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
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 11:54:29 -0000
--047d7b4508de264bbc0522b0288e
Content-Type: text/plain; charset=UTF-8
Indeed the reason I got started with all of this is the use of normalized
transaction IDs within smart contracts with multiple signers. Sorry if I
was perceived as overselling it :-)
So to summarize the discussions that have been on-going here as well as in
the PR so far, most people seem to agree that the BIP is an improvement for
smart-contracts as well as the third-party modification scenario. It comes
at the cost of increased UTXO size due to the additional hash being stored
per transaction with unclaimed outputs and some additional computations.
The additional computation is for the normalized ID computation and the
swapping in of normalized IDs during verification. No additional coin
lookups are needed as they are retrieved and cached anyway when verifying
the transaction. Would everybody agree with this assessment so far?
On the PR there were some additional suggestions of treating singlesig
transactions as 1-of-1 transactions and using Schnorr signatures for the
new opcode. Schnorr has been in the works for a long time and gives a
multitude of advantages, e.g., batch validation, and seems like a good
addition. Since the verify flag is mandatory due to the soft-fork migration
and we might merge singlesig and multisig into a single opcode we can
replace the bitmap of flags with a simple version number. Clients would
fall back to OP_NOP behaviour for versions they do not implement,
maintaining soft-fork semantics to build more future signing and
verification methods.
On Thu, Oct 22, 2015 at 10:57 AM Gregory Maxwell <gmaxwell@gmail.com> wrote:
> 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.
>
--047d7b4508de264bbc0522b0288e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Indeed the reason I got started with all of this is the us=
e of normalized transaction IDs within smart contracts with multiple signer=
s. Sorry if I was perceived as overselling it :-)<div><br></div><div>So to =
summarize the discussions that have been on-going here as well as in the PR=
so far, most people seem to agree that the BIP is an improvement for smart=
-contracts as well as the third-party modification scenario. It comes at th=
e cost of increased UTXO size due to the additional hash being stored per t=
ransaction with unclaimed outputs and some additional computations. The add=
itional computation is for the normalized ID computation and the swapping i=
n of normalized IDs during verification. No additional coin lookups are nee=
ded as they are retrieved and cached anyway when verifying the transaction.=
Would everybody agree with this assessment so far?</div><div><br></div><di=
v>On the PR there were some additional suggestions of treating singlesig tr=
ansactions as 1-of-1 transactions and using Schnorr signatures for the new =
opcode. Schnorr has been in the works for a long time and gives a multitude=
of advantages, e.g., batch validation, and seems like a good addition. Sin=
ce the verify flag is mandatory due to the soft-fork migration and we might=
merge singlesig and multisig into a single opcode we can replace the bitma=
p of flags with a simple version number. Clients would fall back to OP_NOP =
behaviour for versions they do not implement, maintaining soft-fork semanti=
cs to build more future signing and verification methods.</div><div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Oct 22, 2015 at 10:57 AM G=
regory Maxwell <<a href=3D"mailto:gmaxwell@gmail.com">gmaxwell@gmail.com=
</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Oct 22, 201=
5 at 8:26 AM, Christian Decker via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> Normalized transaction IDs do help in the case that the single signer =
wants<br>
> to immediately follow up its transaction with another transaction spen=
ding<br>
> the first one's change output, and it prevents any modification in=
the<br>
> multi-signer scenario.<br>
<br>
For ordinary transactions which are not performing interesting smart<br>
contracts that particular is better addressed via canonical encoding,<br>
which is immediately available and doesn't have the associated costs<br=
>
(new pubkey type adoption, 20%-30% UTXO size increase, need for nodes<br>
to fixup txid references, etc.).<br>
<br>
Please, as I said up-thread: this is good and importantstuff to work<br>
on, but it shouldn't be oversold.<br>
</blockquote></div></div></div>
--047d7b4508de264bbc0522b0288e--
|
