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
|
Return-Path: <tomz@freedommail.ch>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1FF86B43
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2016 12:09:45 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mx-out01.mykolab.com (mx.kolabnow.com [95.128.36.1])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2F9168A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2016 12:09:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at kolabnow.com
X-Spam-Score: -2.9
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102])
by mx-out01.mykolab.com (Postfix) with ESMTPS id 6B88161614;
Thu, 22 Sep 2016 14:09:40 +0200 (CEST)
From: Tom <tomz@freedommail.ch>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Thu, 22 Sep 2016 14:09:38 +0200
Message-ID: <6286144.BZfBM3Z3un@garp>
In-Reply-To: <20160922111049.GA592@nex>
References: <7844645.RLYLWYmWtM@garp> <1988067.b5KirJFSKj@garp>
<20160922111049.GA592@nex>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 22 Sep 2016 12:40:26 +0000
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: Thu, 22 Sep 2016 12:09:45 -0000
On Thursday 22 Sep 2016 13:10:49 Christian Decker via bitcoin-dev wrote=
:
> On Thu, Sep 22, 2016 at 10:56:31AM +0200, Tom via bitcoin-dev wrote:
> > On Wednesday 21 Sep 2016 18:01:30 Gregory Maxwell via bitcoin-dev w=
rote:
> > > On Tue, Sep 20, 2016 at 5:15 PM, Tom via bitcoin-dev
> > >=20
> > > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > > BIP number for my FT spec.
> > >=20
> > > This document does not appear to be concretely specified enough t=
o
> > > review or implement from it.
> > >=20
> > > For example, it does not specify the serialization of "integer"
> >=20
> > It refers to the external specification which is linked at the bott=
om.
> > In that spec you'll see that "Integer" is the standard var-int that=
> > Bitcoin
> > has used for years.
>=20
> I think BIPs should be self-contained, or rely on previous BIPs,
> whenever possible. Referencing an external formatting document should=
> be avoided=20
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.
> > > nor does it specify how the
> > > presence of the optional fields are signaled
> >=20
> > How does one signals an optional field except of in the spec? Thats=
the
> > job of a specification.
>=20
> So the presence is signaled by encountering the tag, which contains
> both token type and name-reference. The encoder and decoder operation=
s
> could be described better.
I'm sorry, I'm not following you here. Is there a question?
> > > nor the cardinality of
> > > the inputs or outputs.
> >=20
> > Did you miss this in the 3rd table ? I suggest clicking on the git=
hub
> > bips
> > repo link as tables are not easy to read in mediawiki plain format =
that
> > the
> > email contained.
>=20
> Minor nit: that table is not well-formed.
I am not very well versed in mediawiki tables, and I found github has s=
ome=20
incompatibilities too.
The markdown one looks better;
https://github.com/bitcoinclassic/documentation/blob/master/spec/transa=
ctionv4.md
> 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 a=
nd re-
signing it is not changing anything. Its re-creating. Something that th=
e owner=20
of the coin has every right to do.
> 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.=20
Sorry, what is evident? You seem to imply that it is uncommon that you =
can=20
create two transactions of similar intent but using different bytes.
You would be wrong with this implication as this is very common. You ca=
n just=20
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=
=20
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;=20
=ABTxInPrevHash and TxInPrevIndex
Index can be skipped, but in any input the PrevHash always has
to come first=BB
If you still see something alarming, let me know.
You can look at the code in Bitcoin Classic and notice that it really i=
sn't=20
anything complicated or worrying.
> Finally, allowing miners to reject transactions with unknown fields
> makes the OP_NOPs unusable=20
Hmm, it looks like you are mixing terminology and abstraction-levels. =
OP_NOP=20
is a field from script and there is no discussion about any rejection b=
ased on=20
script in this BIP at all.
Rejection of transactions is done on there being unrecognised tokens in=
the=20
transaction formatting itself.
Thank you for your email to my BIP, I hope you got the answers you were=
=20
looking for :)
|
