On Sat, Nov 5, 2011 at 4:39 PM, Amir Taaki <zgenjix@yahoo.com> wrote:

From talking with Patrick Strateman (phantomcircuit), he su= ggested this idea (which I will elaborate more on in the BIP):

User-agent strings are a good starting point, however they aren&= #39;t easy for parsing so we'll make a small modification to them.

We need a hierarchy from pro= tocol, variant, gui, flavour, build

/Satoshi:314700/b= itcoin-qt:0.4/

How does = that sound? In BitcoinJ's case:

/BitcoinJ:0.2/AndroidBuild:0.8/

Thoughts:

<= span>- Do we need a freely defined comments field?

/BitcoinJ:0.2[iP= ad; U; CPU OS 3_2_1]/AndroidBuild:0.8/

/Satoshi:3147= 00/bitcoin-qt:0.4[Ubuntu Oneiric]/

From: Christian Decker <decker.christian@gmail.com>= ;
To: Mike Hearn <mike@plan99.net>
Cc: Amir Taaki <zgenjix@yahoo.com>; &quo= t;bitcoin-development@lists.sourceforge.net" <bitcoin-d= evelopment@lists.sourceforge.net>
Sent: Saturday, November 5, = 2011 2:45 PM
Subject: Re: [Bitcoin-development] Lock protocol version numbers

On BitDroid I stopped updating the protocol version at 31700 and set t= he string to be both Version and Client, just like BitcoinJ :-)

On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn <mike@plan99.ne= t> wrote:

BitCoinJ already sets the subver field to its name and version.

-----------------------------------------------------------------------= -------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.s= f.net/sfu/rsa-sfdev2dev1
___________________________________________= ____
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/li= stinfo/bitcoin-development

----------------------------------------------------------= --------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.s= f.net/sfu/rsa-sfdev2dev1
___________________________________________= ____
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--bcaec5485a6ea5db9304b0ff2c51-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RMj7d-0003HA-2w for bitcoin-development@lists.sourceforge.net; Sat, 05 Nov 2011 16:29:33 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1RMj7c-0006tp-8u for bitcoin-development@lists.sourceforge.net; Sat, 05 Nov 2011 16:29:33 +0000 Received: from ishibashi.localnet (fl-184-4-160-40.dhcp.embarqhsd.net [184.4.160.40]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id D0804D9007D; Sat, 5 Nov 2011 16:29:26 +0000 (UTC) From: "Luke-Jr" To: bitcoin-development@lists.sourceforge.net Date: Sat, 5 Nov 2011 12:29:15 -0400 User-Agent: KMail/1.13.7 (Linux/3.1.0-gentoo; KDE/4.6.5; x86_64; ; ) References: <1320268981.72296.YahooMailNeo@web121003.mail.ne1.yahoo.com> <1320507589.87534.YahooMailNeo@web121019.mail.ne1.yahoo.com> In-Reply-To: X-PGP-Key-Fingerprint: CE5A D56A 36CC 69FA E7D2 3558 665F C11D D53E 9583 X-PGP-Key-ID: 665FC11DD53E9583 X-PGP-Keyserver: x-hkp://subkeys.pgp.net MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201111051229.16790.luke@dashjr.org> X-Spam-Score: -1.2 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1RMj7c-0006tp-8u 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 16:29:33 -0000 On Saturday, November 05, 2011 12:17:58 PM Christian Decker wrote: > Sorry for shooting this approach down, but I'm against it. User-agent > strings are an extremely bad idea as it would lead developers to start > making communication choices depending on the client type. This can be necessary in some cases. What happens when some popular client is found with a subtle bug, and cannot otherwise be differentiated from other similar-functionality clients? I have found User-Agent very valuable when dealing with the wide variety of miner bugs when I have enabled new functionality/behaviour on Eligius. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RMjI2-0003VU-Sm for bitcoin-development@lists.sourceforge.net; Sat, 05 Nov 2011 16:40:18 +0000 X-ACL-Warn: Received: from nm30-vm2.bullet.mail.ne1.yahoo.com ([98.138.91.130]) by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1RMjI2-0002nD-6Z for bitcoin-development@lists.sourceforge.net; Sat, 05 Nov 2011 16:40:18 +0000 Received: from [98.138.90.51] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 05 Nov 2011 16:40:12 -0000 Received: from [98.138.89.194] by tm4.bullet.mail.ne1.yahoo.com with NNFMP; 05 Nov 2011 16:40:12 -0000 Received: from [127.0.0.1] by omp1052.mail.ne1.yahoo.com with NNFMP; 05 Nov 2011 16:40:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 843935.73925.bm@omp1052.mail.ne1.yahoo.com Received: (qmail 71104 invoked by uid 60001); 5 Nov 2011 16:40:12 -0000 X-YMail-OSG: q1CAt1wVM1n19XX8hHra1sR.LQRo2Gb15RZt4bCZUsnII7s FiO8lcojrXfJ8ps3WNDxOYzRFZ9uQIUNNAGZchqMvJjsB10gyb3vlDM5Xv4z Usub_7nB4MjcOARq.KLdUPxvFsXjWpYpftInkMbxYkUgKLV50ze0NMtZUqDK 6q0QierWreSIu.jEnBrcBLrP5I_g7OrWYW0EHiyiQ6E3PqMq7I8sWSBq82zM jVVJ5Pd97tRGL13.yMv8wK33jqWYvGjLyiTjAMSWeR.7ufmEVjynb10gSiBD v8ylI19sToh6xN7hH3kgtq7tRwcUspDd7gTB6SvbYoECY3wqah_b9iOAOiQt grzy6_bCKFenZBKhEKhFeQlL9ekp3Pu_pH61DaCopnK6DvxSL_CuHX7g6TA- - Received: from [2.97.171.28] by web121017.mail.ne1.yahoo.com via HTTP; Sat, 05 Nov 2011 09:40:12 PDT X-Mailer: YahooMailWebService/0.8.115.325013 References: <1320268981.72296.YahooMailNeo@web121003.mail.ne1.yahoo.com> <1320507589.87534.YahooMailNeo@web121019.mail.ne1.yahoo.com> <201111051229.16790.luke@dashjr.org> Message-ID: <1320511212.70648.YahooMailNeo@web121017.mail.ne1.yahoo.com> Date: Sat, 5 Nov 2011 09:40:12 -0700 (PDT) From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: <201111051229.16790.luke@dashjr.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-71337780-990759556-1320511212=:70648" X-Spam-Score: -0.3 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [98.138.91.130 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zgenjix[at]yahoo.com) -1.2 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1RMjI2-0002nD-6Z Subject: Re: [Bitcoin-development] Lock protocol version numbers X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Amir Taaki List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 16:40:19 -0000 ---71337780-990759556-1320511212=:70648 Content-Type: text/plain; charset=us-ascii On Saturday, November 05, 2011 12:17:58 PM Christian Decker wrote: >> Sorry for shooting this approach down, but I'm against it. User-agent >> strings are an extremely bad idea as it would lead developers to start >> making communication choices depending on the client type. > This can be necessary in some cases. What happens when some popular client is > found with a subtle bug, and cannot otherwise be differentiated from other > similar-functionality clients? I have found User-Agent very valuable when > dealing with the wide variety of miner bugs when I have enabled new > functionality/behaviour on Eligius. I can agree with this point though. 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. Fail hard and fast. 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. Lets say with libbitcoin- I'm sure that users of libbitcoin would like to have their client name in the string somehow. This was we can quickly understand which code-bases are being used and all the variants that exist build on those code-bases. Together with system information (how many Linux users are there?) and various system settings (how many 32bit users are there), and so on. ---71337780-990759556-1320511212=:70648 Content-Type: text/html; charset=us-ascii

On Saturday, November 05, 2011 12:17:58 PM Christian Decker wrote:
>> Sorry for shooting this approach down, but I'm against it. User-agent
>> strings are an extremely bad idea as it would lead developers to start
>> making communication choices depending on the client type.
> This can be necessary in some cases. What happens when some popular client is
> found with a subtle bug, and cannot otherwise be differentiated from other
> similar-functionality clients? I have found User-Agent very valuable when
> dealing with the wide variety of miner bugs when I have enabled new
> functionality/behaviour on Eligius.

I can agree with this point though. 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.

Fail hard and fast.

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. Lets say with libbitcoin- I'm sure that users of libbitcoin would like to have their client name in the string somehow. This was we can quickly understand which code-bases are being used and all the variants that exist build on those code-bases.

Together with system information (how many Linux users are there?) and various system settings (how many 32bit users are there), and so on.

---71337780-990759556-1320511212=:70648-- From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 Message-ID: <4EB5729A.7090205@parhelic.com> Date: Sat, 05 Nov 2011 10:30:02 -0700 From: Jordan Mack 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> <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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.