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
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
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 F3FCEBFF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 23 Sep 2016 11:42:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1442C1CA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 23 Sep 2016 11:42:39 +0000 (UTC)
Received: by mail-wm0-f47.google.com with SMTP id l132so25048718wmf.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 23 Sep 2016 04:42:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=date:from:to:subject:message-id:mail-followup-to:references
:mime-version:content-disposition:content-transfer-encoding
:in-reply-to:user-agent;
bh=+jUvItm/gsacXHuCCBzr0qn12v1ZkrHQMgw/BYlGfqM=;
b=Bb661zjcwxDR9Li0VEdtPXseBc9I/MOSVaxZFZhGHttGRiheZhjxZTAhb/ZrcPIA2V
vcM+bNozKKJHiEa4vBY4X1J3CGPMEQD4H/xk+4QeeX/fw3Jk/pZ/ohmGZg6gREI0KERx
kMnxHGbzWU6rTnlruCe/5Ij9LSjQpZcP+6U8XByEWvpQCSwVSyg6wQOyerW6lrR17sjq
DL/0evBX7iYOkmkO9knnz9kQJ3Xeov9oxK4KgyBS524aH8iWe9tyIeaUMM+twJBQHmGo
zMMiIzD/VDVo8fTL6zFbR1PdDIlWjscbeNQwdKLbbcQLk15cK23TfgRicnEG3mIy8myG
rbpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to
:references:mime-version:content-disposition
:content-transfer-encoding:in-reply-to:user-agent;
bh=+jUvItm/gsacXHuCCBzr0qn12v1ZkrHQMgw/BYlGfqM=;
b=MXwNvL0NBojvOc6XHq96U3n6ovU1l2rTsqhRQrM2Q50L++Fv1kdWw0gkimAzGqx/qd
mdMSWAYAyDbUWlHd/OeAhKPjeEtiDY6MkE1BclpmoV6fZFywds69kJNWiRWjZnzEGsdU
7dyec/3MNg7SkIOiMqikwZekrVv7CKiS7yietnmueqzxpJv4scklC7ubbnWVjYng8sEt
ysnKqZbiTES6ubXgCaSrOkcm97NOX5Y62TXMXOaTeOAKbLgL6bGxp1LlZF3WDtTcg11p
BSTKr6VdC8MLtBIpy6+vZBc4M3TTxJUQO47paIbP97sYokkc7i1kvgawtNRcr+3YaFEc
/E8A==
X-Gm-Message-State: AA6/9RmMwrkcz3LEyCXfJYZzgG+vVsuFDhV9GHX588LK5+j6pN6KyYKIk9zBywBlYGwEmw==
X-Received: by 10.28.14.20 with SMTP id 20mr2666989wmo.6.1474630957527;
Fri, 23 Sep 2016 04:42:37 -0700 (PDT)
Received: from nex ([2a02:aa16:1105:4a80:eca1:a51:7a7c:5e35])
by smtp.gmail.com with ESMTPSA id g7sm6798663wjc.43.2016.09.23.04.42.36
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=AES128-SHA bits=128/128);
Fri, 23 Sep 2016 04:42:36 -0700 (PDT)
Date: Fri, 23 Sep 2016 13:42:36 +0200
From: Christian Decker <decker.christian@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20160923114236.GA17871@nex>
Mail-Followup-To: Christian Decker <decker.christian@gmail.com>,
bitcoin-dev@lists.linuxfoundation.org
References: <7844645.RLYLWYmWtM@garp> <1988067.b5KirJFSKj@garp>
<20160922111049.GA592@nex> <6286144.BZfBM3Z3un@garp>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6286144.BZfBM3Z3un@garp>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Fri, 23 Sep 2016 11:42:40 -0000
On Thu, Sep 22, 2016 at 02:09:38PM +0200, Tom via bitcoin-dev wrote:
> On Thursday 22 Sep 2016 13:10:49 Christian Decker via bitcoin-dev wrote:
> >
> > I think BIPs should be self-contained, or rely on previous BIPs,
> > whenever possible. Referencing an external formatting document should
> > be avoided
>
> If luke-jr thinks I should submit CMF as a BIP, I can certainly do that.
> Luke, what do you think?
>
> I don't have a preference either way.
>
> >
> > So the presence is signaled by encountering the tag, which contains
> > both token type and name-reference. The encoder and decoder operations
> > could be described better.
>
> I'm sorry, I'm not following you here. Is there a question?
Nope, just clarifying how presence or absence is indicated :-)
> >
> > Minor nit: that table is not well-formed.
>
> I am not very well versed in mediawiki tables, and I found github has some
> incompatibilities too.
> The markdown one looks better;
> https://github.com/bitcoinclassic/documentation/blob/master/spec/transactionv4.md
It's just some rows have 3 columns, others have 2. It's a minor nit
really.
> > As was pointed out in the
> > normalized transaction ID BIP, your proposal only addresses
> > third-party malleability, since signers can simply change the
> > transaction and re-sign it.
>
> I have to disagree. That is not malleability. Creating a new document and re-
> signing it is not changing anything. Its re-creating. Something that the owner
> of the coin has every right to do.
Same thing I was arguing back then, however Luke pointed out that
malleability just refers to the possibility of modifying a transaction
after the fact. Always referring to "third-party malleability" avoids
this ambiguity.
> > This is evident from the fact that inputs
> > and outputs do not have a canonical order and it would appear that
> > tokens can be re-ordered in segments.
>
> Sorry, what is evident? You seem to imply that it is uncommon that you can
> create two transactions of similar intent but using different bytes.
> You would be wrong with this implication as this is very common. You can just
> alter the order of the inputs, for instance.
>
> I am unable to see what the point is you are trying to make. Is there a
> question or a suggestion for improvement here?
>
> > Dependencies of tokens inside a
> > segment are also rather alarming (TxInPrevHash <-> TxInPrevIndex,
> > TxOutScript <-> TxOutValue).
>
> Maybe you missed this line;
> «TxInPrevHash and TxInPrevIndex
> Index can be skipped, but in any input the PrevHash always has
> to come first»
Nope, that is exactly the kind of dependency I was talking
about. Instead of nesting a construct like the current transactions
do, you rely on the order of tokens to imply that they belong
together.
> If you still see something alarming, let me know.
> You can look at the code in Bitcoin Classic and notice that it really isn't
> anything complicated or worrying.
>
>
> > Finally, allowing miners to reject transactions with unknown fields
> > makes the OP_NOPs unusable
>
> Hmm, it looks like you are mixing terminology and abstraction-levels. OP_NOP
> is a field from script and there is no discussion about any rejection based on
> script in this BIP at all.
>
> Rejection of transactions is done on there being unrecognised tokens in the
> transaction formatting itself.
Ah, thanks for clearing that up. However, the problem persists, if we
add new fields that a non-upgraded node doesn't know about and it
rejects transactions containing it, we'll have a hard-fork. It should
probably not reject transactions with unknown fields if the
transaction is included in a block.
> Thank you for your email to my BIP, I hope you got the answers you were
> looking for :)
Cheers,
Christian
|
