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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WziWd-0001Ab-EH
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Jun 2014 08:25:51 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.172 as permitted sender)
client-ip=209.85.214.172; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f172.google.com;
Received: from mail-ob0-f172.google.com ([209.85.214.172])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WziWb-0001rP-LJ
for bitcoin-development@lists.sourceforge.net;
Wed, 25 Jun 2014 08:25:51 +0000
Received: by mail-ob0-f172.google.com with SMTP id uy5so1697950obc.17
for <bitcoin-development@lists.sourceforge.net>;
Wed, 25 Jun 2014 01:25:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.52.77 with SMTP id r13mr6128279oeo.55.1403684744017; Wed,
25 Jun 2014 01:25:44 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.35.234 with HTTP; Wed, 25 Jun 2014 01:25:43 -0700 (PDT)
In-Reply-To: <C95DB811-9E6A-4EA2-AE8F-83595C3AC817@gmail.com>
References: <CANEZrP3iyQ9zQ+hDnooxrjdBO+_Fj+nAkK1Skgk+Gb4gkidPhQ@mail.gmail.com>
<CAJHLa0Omiz+UhGjSKgYU7+b2YY7aN23w7o8CQntqMePFs7LkjA@mail.gmail.com>
<CANEZrP06gk-JhKaNpvYUTfjFq9AGnCay9=pjUGpVMjMSuX3_ew@mail.gmail.com>
<CAJna-HhX8HOci0KMe4ZScr4QW792S3n5twvU0QhbQe1N_3q7_w@mail.gmail.com>
<6E6F88E9-5698-419B-927C-F65A5FCABBE9@gmail.com>
<CAJHLa0PYfuJg3daPvzPFZpFz7ezH2RHpJ8zyz2g1NDKppM7rWA@mail.gmail.com>
<BBF86C9B-6B3D-4A03-AC7B-35619C47091F@gmail.com>
<CABsx9T13yksenx5aYd4HVqTyVjARx9aTHy=Neu64p6k9FnRRVw@mail.gmail.com>
<C95DB811-9E6A-4EA2-AE8F-83595C3AC817@gmail.com>
Date: Wed, 25 Jun 2014 10:25:43 +0200
X-Google-Sender-Auth: 0FTtRSWTafZBC4vGLilqS0uqrQQ
Message-ID: <CANEZrP0ce4MMX2hOhcGVWt23L_CMn6Cmj9_Okqd0BR9seQXJew@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gmail <will.yager@gmail.com>
Content-Type: multipart/alternative; boundary=001a11330d028b3e7104fca4d26a
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WziWb-0001rP-LJ
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed BIP 70 extension
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 25 Jun 2014 08:25:51 -0000
--001a11330d028b3e7104fca4d26a
Content-Type: text/plain; charset=UTF-8
>
> I agree. It would be even sillier to start specifying container formats
> for random one-off "that would be kind of nice, I guess" features.
>
No, it'd be sensible.
Here's a list I drew up a long time ago of features I imagined adding to
the payment protocol:
https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147
The protocol is there to contain features! There is zero benefit to
slavishly following some religious notion of purity or minimalism here. The
shared resource in question is just varint encoded integers. So, we should
be guided by what will help our users and what will help adoption.
Anyway, Gavin asked me to start handling more BIP 70 stuff a few weeks ago.
I want to use something simple to set up the extensions process more
formally. IMO we need a "living document" version of the payment protocol
with all the different extensions out there folded into it, to simplify
programming tasks and ensure field numbers don't collide.
--001a11330d028b3e7104fca4d26a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
<div class=3D"">I agree. It would be even sillier to start specifying conta=
iner formats for random one-off "that would be kind of nice, I guess&q=
uot; features.</div></blockquote><div><br></div><div>No, it'd be sensib=
le.</div>
<div><br></div><div>Here's a list I drew up a long time ago of features=
I imagined adding to the payment protocol:</div><div><br></div><div><a hre=
f=3D"https://bitcointalk.org/index.php?topic=3D270055.msg2890147#msg2890147=
">https://bitcointalk.org/index.php?topic=3D270055.msg2890147#msg2890147</a=
></div>
<div><br></div><div>The protocol is there to contain features! There is zer=
o benefit to slavishly following some religious notion of purity or minimal=
ism here. The shared resource in question is just varint encoded integers. =
So, we should be guided by what will help our users and what will help adop=
tion.</div>
<div><br></div><div>Anyway, Gavin asked me to start handling more BIP 70 st=
uff a few weeks ago. I want to use something simple to set up the extension=
s process more formally. IMO we need a "living document" version =
of the payment protocol with all the different extensions out there folded =
into it, to simplify programming tasks and ensure field numbers don't c=
ollide.</div>
</div></div></div>
--001a11330d028b3e7104fca4d26a--
|
