> 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
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 necessa
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
> *Cc:* Amir Taaki ; "
> 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
qt:0.4[Ubuntu Oneiric]/
From: Christian Decker
To: Mike Hearn
Cc: Amir Taaki ; "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 updatin
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 wrote:
> BitCoinJ already sets the subver field to its name and version.
>
>
>
> --
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-developmen
On Wed, Nov 2, 2011 at 7:22 PM, Christian Decker
wrote:
> The mainline client (independently from the GUI) has been referenced to as
> "Satoshi" client. I personally like the name as a homage, but I guess it all
> comes down to the decision of the maintainers.
That's how I take it to mean: "sato
The mainline client (independently from the GUI) has been referenced to as
"Satoshi" client. I personally like the name as a homage, but I guess it
all comes down to the decision of the maintainers.
Regards,
Chris
On Thu, Nov 3, 2011 at 12:07 AM, Luke-Jr wrote:
> On Wednesday, November 02, 2011
On Wednesday, November 02, 2011 6:55:27 PM Amir Taaki wrote:
> I think calling it Satoshi is apt homage to the person who made the
> original client reference protocol.
My point is that the "Satoshi client" was the wxWidgets client, which was
retired by 0.5.
-
Cool thread. I enjoyed reading that :) Thanks for sharing.
From: Christian Decker
To: Amir Taaki
Cc: "bitcoin-development@lists.sourceforge.net"
Sent: Wednesday, November 2, 2011 10:42 PM
Subject: Re: [Bitcoin-development] Lock protocol version numb
, 2011 10:46 PM
Subject: Re: [Bitcoin-development] Lock protocol version numbers
On Wednesday, November 02, 2011 6:33:12 PM Amir Taaki wrote:
> "Satoshi 0.5"
What is "Satoshi 0.5" anyway? 0.5's server is bitcoind and GUI is Bitcoin-Qt;
the wx GUI client is gone, which is
On Wednesday, November 02, 2011 6:33:12 PM Amir Taaki wrote:
> "Satoshi 0.5"
What is "Satoshi 0.5" anyway? 0.5's server is bitcoind and GUI is Bitcoin-Qt;
the wx GUI client is gone, which is more or less what "Satoshi" referred to in
the past...
-
> Although there would be little reason for this with a sane protocol
> versioning scheme.
>
> If we're agreed then I'll start on that BIP.
>
> --
> *From:* Gavin Andresen
> *To:* Amir Taaki
> *Sent:* Wednesday, November 2, 2011 9:34
his with a sane protocol versioning
scheme.
If we're agreed then I'll start on that BIP.
From: Gavin Andresen
To: Amir Taaki
Sent: Wednesday, November 2, 2011 9:34 PM
Subject: Re: [Bitcoin-development] Lock protocol version numbers
Good idea.
Sounds perf
I don't really get what you want to achieve with this. The protocol will be
slow down evolution (hopefully) soon, while the clients will continue
releasing at a similar rhythm. It took long enough to decouple the protocol
version from being bumped each client release, now doing the inverse
coupling
Hey,
Can we lock the version numbers to be the protocol version (which changes
rarely) and instead use the sub_version_num field + revision number for
individual builds?
Satoshi 0.4
BitcoinJava 120311
bitcoin-js 6
Like so. Otherwise we will have version bumping insanity :)
17 matches
Mail list logo
