onservatism.
>
>
>
> - Original Message -
> From: Jeff Garzik
> To: Wladimir
> Cc: bitcoin-development@lists.sourceforge.net
> Sent: Sunday, June 17, 2012 5:19 PM
> Subject: Re: [Bitcoin-development] Proposed new P2P command and response:
> getcmds, cmdlist
>
&g
ry to hedge
against that kind of feeling towards conservatism.
- Original Message -
From: Jeff Garzik
To: Wladimir
Cc: bitcoin-development@lists.sourceforge.net
Sent: Sunday, June 17, 2012 5:19 PM
Subject: Re: [Bitcoin-development] Proposed new P2P command and response:
getcmds, cmd
On Sat, Jun 16, 2012 at 4:42 AM, Wladimir wrote:
> Which is a perfectly reasonable requirement. However, one could simply
> standardize what a 'thin client' and what a 'thick client' does and offers
> (at a certain version level), without having to explicitly enumerate
> everything over the protoc
On Saturday 16 Jun 2012 09:42:21 Wladimir wrote:
> Which is a perfectly reasonable requirement. However, one could simply
> standardize what a 'thin client' and what a 'thick client' does and
> offers (at a certain version level), without having to explicitly
> enumerate everything over the protoc
le is slowing the
long-term evolution of Bitcoin down.
From: Wladimir
To: Andy Parkins
Cc: bitcoin-development@lists.sourceforge.net
Sent: Saturday, June 16, 2012 10:42 AM
Subject: Re: [Bitcoin-development] Proposed new P2P command and response:
getcmds, c
On Sat, Jun 16, 2012 at 10:16 AM, Andy Parkins wrote:
>
> It's less of a problem in a (nearly) stateless protocol like Bitcoin.
>
It's currently (nearly) stateless, however it would be short-sighted to
think it will stay that way. State is being introduced as we speak; for
example, connection-spe
On Saturday 16 Jun 2012 02:34:53 Amir Taaki wrote:
> Introspection/command discovery is nice, but I would prefer it to be
> immediately done in the first version exchange so no assumptions as to
> how a network is operating need to be made.
That would need a change of the current version message.
On Saturday 16 Jun 2012 07:45:00 Wladimir wrote:
> As replied on the github issue:
>
> Personally I still think it's better to have a clear standardized
> "protocol version", that implies what capabilities are supported,
> instead of a capability-based system that explicitly lists them.
>
> Capab
ion file which is held on github or bitcoin.org/
>
>
> - Original Message -
> From: Jeff Garzik
> To: Bitcoin Development
> Cc:
> Sent: Saturday, June 16, 2012 2:13 AM
> Subject: [Bitcoin-development] Proposed new P2P command and response:
> getcmds, cmdlist
>
aturday, June 16, 2012 2:13 AM
Subject: [Bitcoin-development] Proposed new P2P command and response: getcmds,
cmdlist
Outside of major features advertised network-wide in nService bits,
P2P protocol lacks a good method of enumerating minor features or
extensions. The version number increment is c
Outside of major features advertised network-wide in nService bits,
P2P protocol lacks a good method of enumerating minor features or
extensions. The version number increment is coarse-grained, and is
not self-documenting. A simple extension which lists supported
commands is added, as demonstrate
11 matches
Mail list logo
