Re: [Bitcoin-development] Lock protocol version numbers
BitCoinJ already sets the subver field to its name and version. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
On BitDroid I stopped updating the protocol version at 31700 and set the string to be both Version and Client, just like BitcoinJ :-) On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn m...@plan99.net 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.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
From talking with Patrick Strateman (phantomcircuit), he suggested this idea (which I will elaborate more on in the BIP): User-agent strings are a good starting point, however they aren't easy for parsing so we'll make a small modification to them. We need a hierarchy from protocol, variant, gui, flavour, build /Satoshi:314700/bitcoin-qt:0.4/ How does that sound? In BitcoinJ's case: /BitcoinJ:0.2/AndroidBuild:0.8/ Thoughts: - Do we need a freely defined comments field? /BitcoinJ:0.2[iPad; U; CPU OS 3_2_1]/AndroidBuild:0.8/ /Satoshi:314700/bitcoin-qt:0.4[Ubuntu Oneiric]/ From: Christian Decker decker.christ...@gmail.com To: Mike Hearn m...@plan99.net Cc: Amir Taaki zgen...@yahoo.com; bitcoin-development@lists.sourceforge.net bitcoin-development@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 the string to be both Version and Client, just like BitcoinJ :-) On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn m...@plan99.net 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.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
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. User-Agents in HTTP are only useful if the clients (browsers) do not adhere to a well defined behavior. I see the version string more as a kind of vanity point (xyz peers are using my network code) and it would be bad to base choices on it. For protocol choices we already have a good mechanism in place (nServices) to negotiate capabilities. I for one vote for keeping it as simple as possible, just a simple string, without any further meaning. On Sat, Nov 5, 2011 at 4:39 PM, Amir Taaki zgen...@yahoo.com wrote: From talking with Patrick Strateman (phantomcircuit), he suggested this idea (which I will elaborate more on in the BIP): User-agent strings are a good starting point, however they aren't easy for parsing so we'll make a small modification to them. We need a hierarchy from protocol, variant, gui, flavour, build /Satoshi:314700/bitcoin-qt:0.4/ How does that sound? In BitcoinJ's case: /BitcoinJ:0.2/AndroidBuild:0.8/ Thoughts: - Do we need a freely defined comments field? /BitcoinJ:0.2[iPad; U; CPU OS 3_2_1]/AndroidBuild:0.8/ /Satoshi:314700/bitcoin-qt:0.4[Ubuntu Oneiric]/ -- *From:* Christian Decker decker.christ...@gmail.com *To:* Mike Hearn m...@plan99.net *Cc:* Amir Taaki zgen...@yahoo.com; bitcoin-development@lists.sourceforge.net bitcoin-development@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 the string to be both Version and Client, just like BitcoinJ :-) On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn m...@plan99.net 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.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
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. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
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. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
