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
|
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 B7EDFBA4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2016 11:10:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 28656142
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2016 11:10:55 +0000 (UTC)
Received: by mail-wm0-f46.google.com with SMTP id l132so321130426wmf.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Sep 2016 04:10:55 -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:in-reply-to:user-agent;
bh=GfRbghQ5NuV23L7ivsGrxeiIAr/Y+lfr3OgKPLRUpYQ=;
b=rfk8I6Qed1iGHLKc4zAG5TNZ9c++GK2Q1NbHdpKRtm4gTCSxJSGGLq67N6YTPUDsJw
WSAlz3sK8tCPGImOgCu2XawGAfPlm9f4UqyH1kKqdSB4Hv7kZhFFtojaJMbpfJDB5ESw
3X0epuMuoHWS6JAdX+VtFuePs82S6xIVLhqZYl4mfGYmswj9mghM2lCtYmaQWyX1uuXI
ZAQKDTg5ErMdtKb47FrC+amc2Rpwz3BzDskcCMcaS+BfE3+0UclBl8iJoQzqZJ3wmvPK
1RrkleEnTKvsryp4BQlfXx4AAfYbVKH/mW+0o6/3r9OgMHBYQg57+bv/E+qlYU6xt+2t
fodg==
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:in-reply-to:user-agent;
bh=GfRbghQ5NuV23L7ivsGrxeiIAr/Y+lfr3OgKPLRUpYQ=;
b=eIXIo/GVVPFUca/AZNLP8s4/cK0M+I1Tnarh2+mwCJYlVpdnWDtgGTm5NoZ68OLSOn
snR5biu2ep9I5aYDR7U7n/80144Jjp4HCuLXDMuWfUkikzQCwZp9eqmpyTdlWugaOv6O
as5oTvohaAEOl3opGKzA48i527SirCV6CZEtC+elwbFMHEv63LfSMi3oUCfe2YyuGXgn
hQPPsqAtfVyTKx91RmSvRybg/e7RF2OEFdg2xzWeAsUyQZkSdA+UVBnHw8EGBAbcWY3B
07x0B705FNSM7W3QT8U/muL9fVnWa/SeMegievamJSkL6lWeriweeGmjgeXZUeSloPqE
Yh3g==
X-Gm-Message-State: AE9vXwMRhO16jLFmSRVC2HEr+aL4MVX6A1fPt6o9nDSUR9UaNQgWCI38JVlAALYiIm7CmQ==
X-Received: by 10.194.93.198 with SMTP id cw6mr1517975wjb.212.1474542650830;
Thu, 22 Sep 2016 04:10:50 -0700 (PDT)
Received: from nex ([2a02:aa16:1105:4a80:82f:b8ee:4de3:5cdd])
by smtp.gmail.com with ESMTPSA id n7sm1535115wjz.32.2016.09.22.04.10.48
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLS1_2 cipher=AES128-SHA bits=128/128);
Thu, 22 Sep 2016 04:10:48 -0700 (PDT)
Date: Thu, 22 Sep 2016 13:10:49 +0200
From: Christian Decker <decker.christian@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20160922111049.GA592@nex>
Mail-Followup-To: Christian Decker <decker.christian@gmail.com>,
bitcoin-dev@lists.linuxfoundation.org
References: <7844645.RLYLWYmWtM@garp>
<CAAS2fgSpnshZhS7N5R3Qsw_8=NN8sjYGwrnUpdwGzu2TG0-Qgw@mail.gmail.com>
<CAAS2fgT5izjzUVyd3-9sQEHx8rk8pEJWxT6-eDteuUkZdRokAg@mail.gmail.com>
<1988067.b5KirJFSKj@garp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1988067.b5KirJFSKj@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: Thu, 22 Sep 2016 11:10:55 -0000
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 wrote:
> > On Tue, Sep 20, 2016 at 5:15 PM, Tom via bitcoin-dev
> >
> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > BIP number for my FT spec.
> >
> > This document does not appear to be concretely specified enough to
> > review or implement from it.
> >
> > For example, it does not specify the serialization of "integer"
>
> It refers to the external specification which is linked at the bottom.
> In that spec you'll see that "Integer" is the standard var-int that Bitcoin
> has used for years.
I think BIPs should be self-contained, or rely on previous BIPs,
whenever possible. Referencing an external formatting document should
be avoided and requiring readers to reverse engineer a reference
implementation doesn't seem too user friendly either. Publishing a BIP
with CMF would certainly help, and completing this spec with the
details that are missing, or only "defined" in the implementation,
would be better.
> > nor does it specify how the
> > presence of the optional fields are signaled
>
> How does one signals an optional field except of in the spec? Thats the job of
> a specification.
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.
> > nor the cardinality of
> > the inputs or outputs.
>
> Did you miss this in the 3rd table ? I suggest clicking on the github bips
> repo link as tables are not easy to read in mediawiki plain format that the
> email contained.
Minor nit: that table is not well-formed. 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. 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. Dependencies of tokens inside a
segment are also rather alarming (TxInPrevHash <-> TxInPrevIndex,
TxOutScript <-> TxOutValue).
Finally, allowing miners to reject transactions with unknown fields
makes the OP_NOPs unusable since they'd result in forks: non-upgraded
nodes would reject blocks from upgraded nodes.
Regards,
Christian
|
