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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jordanmack1981@gmail.com>) id 1RMk4a-0001tl-GU
for bitcoin-development@lists.sourceforge.net;
Sat, 05 Nov 2011 17:30:28 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.213.47 as permitted sender)
client-ip=209.85.213.47; envelope-from=jordanmack1981@gmail.com;
helo=mail-yw0-f47.google.com;
Received: from mail-yw0-f47.google.com ([209.85.213.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1RMk4Z-000263-Jz
for bitcoin-development@lists.sourceforge.net;
Sat, 05 Nov 2011 17:30:28 +0000
Received: by ywf9 with SMTP id 9so4362358ywf.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 05 Nov 2011 10:30:22 -0700 (PDT)
Received: by 10.50.203.70 with SMTP id ko6mr23701844igc.19.1320514222093;
Sat, 05 Nov 2011 10:30:22 -0700 (PDT)
Received: from [192.168.0.50] (c-67-188-239-72.hsd1.ca.comcast.net.
[67.188.239.72])
by mx.google.com with ESMTPS id mh1sm20168789pbc.11.2011.11.05.10.30.19
(version=SSLv3 cipher=OTHER); Sat, 05 Nov 2011 10:30:20 -0700 (PDT)
Sender: Jordan Mack <jordanmack1981@gmail.com>
Message-ID: <4EB5729A.7090205@parhelic.com>
Date: Sat, 05 Nov 2011 10:30:02 -0700
From: Jordan Mack <jordanmack@parhelic.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <1320268981.72296.YahooMailNeo@web121003.mail.ne1.yahoo.com>
<1320507589.87534.YahooMailNeo@web121019.mail.ne1.yahoo.com>
<CALxbBHWYdt_LRQE5K=36fXNNSqyGVSyYwxi2-p8mxQaei5LCZg@mail.gmail.com>
<201111051229.16790.luke@dashjr.org>
<1320511212.70648.YahooMailNeo@web121017.mail.ne1.yahoo.com>
In-Reply-To: <1320511212.70648.YahooMailNeo@web121017.mail.ne1.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.4 (-)
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
(jordanmack1981[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (jordanmack1981[at]gmail.com)
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: 1RMk4Z-000263-Jz
Subject: Re: [Bitcoin-development] Lock protocol version numbers
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: Sat, 05 Nov 2011 17:30:28 -0000
> If clients break the network protocol/do not comply properly with it,
> they should be disconnected and shunned. Hard love. We don't want any
> ambiguity in the protocol.
> However my feeling about the user-agent string is that it is a vanity
> item, but here we'd be enforcing a format that everybody can
> understand and read.
I agree with Amir completely on both these points.
With something as critical as financial transactions, no exceptions can
be made. The reported client and version should be ignored completely.
If a client does not comply with the protocol, they must be rejected
outright.
It is not in the best interest, or ability, to attempt to micromanage
how developers choose to use the information given. Recommendations and
guidelines can be made, but how they choose to implement is ultimately
their decision. In my opinion, clear and concise definition of the
protocol, and strict adherence in the mainline client, are the best
options available.
The protocol version should be indicated so that it can properly be
handled. Neither the name of the client, or it's version, need to be
reported in this. Protocol validation should ignore this completely.
I do not believe that leaving out the client name and version entirely
is the best option though. As silly as it may seem to some, vanity and
recognition are very strong motivators. We want to encourage more
supporters to the scene, not scare them away. The additional data
provided by this could also be used for calculating various statistics.
It sounds like BitcoinJ and BitDroid have already found ways of adding
it in anyway. I believe it is in the best interest of the developers to
formalize how this information will be included, and use it to their
advantage.
TL;DR: Adhere strictly to the protocol, and reject clients that do not.
Add a user agent string of some kind, but keep it separate from the
protocol version.
|
