* [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
@ 2012-06-16 0:13 Jeff Garzik
2012-06-16 1:34 ` Amir Taaki
0 siblings, 1 reply; 11+ messages in thread
From: Jeff Garzik @ 2012-06-16 0:13 UTC (permalink / raw)
To: Bitcoin Development
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 demonstrated in this pull request:
https://github.com/bitcoin/bitcoin/pull/1471
Another option is for verack to return this information at login,
eliminating the need for a separate command/response.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
2012-06-16 0:13 [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist Jeff Garzik
@ 2012-06-16 1:34 ` Amir Taaki
2012-06-16 6:45 ` Wladimir
2012-06-16 8:17 ` Andy Parkins
0 siblings, 2 replies; 11+ messages in thread
From: Amir Taaki @ 2012-06-16 1:34 UTC (permalink / raw)
To: bitcoin-development
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.
I like the idea of a flat list of commands. It might make sense to have "meta"-commands that alias to groups of commands. i.e "original" for the current core subset up to (and including) "pong". The aliases could exist in a text definition file which is held on github or bitcoin.org/
----- Original Message -----
From: Jeff Garzik <jgarzik@exmulti•com>
To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Cc:
Sent: Saturday, 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 coarse-grained, and is
not self-documenting. A simple extension which lists supported
commands is added, as demonstrated in this pull request:
https://github.com/bitcoin/bitcoin/pull/1471
Another option is for verack to return this information at login,
eliminating the need for a separate command/response.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
2012-06-16 1:34 ` Amir Taaki
@ 2012-06-16 6:45 ` Wladimir
2012-06-16 8:16 ` Andy Parkins
2012-06-16 8:17 ` Andy Parkins
1 sibling, 1 reply; 11+ messages in thread
From: Wladimir @ 2012-06-16 6:45 UTC (permalink / raw)
To: Amir Taaki; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 3264 bytes --]
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.
Capability-based systems (just look at OpenGL) tend to become horrendously
complex, as you have to take into account all possible combinations of
possible interactions, and constantly check for support of specific
features instead of just comparing a version number.
Sure, it can be necessary to distinguish between different types of nodes,
but there is no need to make it this fine-grained.
Wladimir
On Sat, Jun 16, 2012 at 3:34 AM, Amir Taaki <zgenjix@yahoo•com> 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.
>
> I like the idea of a flat list of commands. It might make sense to have
> "meta"-commands that alias to groups of commands. i.e "original" for the
> current core subset up to (and including) "pong". The aliases could exist
> in a text definition file which is held on github or bitcoin.org/
>
>
> ----- Original Message -----
> From: Jeff Garzik <jgarzik@exmulti•com>
> To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
> Cc:
> Sent: Saturday, 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 coarse-grained, and is
> not self-documenting. A simple extension which lists supported
> commands is added, as demonstrated in this pull request:
>
> https://github.com/bitcoin/bitcoin/pull/1471
>
> Another option is for verack to return this information at login,
> eliminating the need for a separate command/response.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti•com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 4643 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
2012-06-16 6:45 ` Wladimir
@ 2012-06-16 8:16 ` Andy Parkins
2012-06-16 8:42 ` Wladimir
0 siblings, 1 reply; 11+ messages in thread
From: Andy Parkins @ 2012-06-16 8:16 UTC (permalink / raw)
To: bitcoin-development
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.
>
> Capability-based systems (just look at OpenGL) tend to become
> horrendously complex, as you have to take into account all possible
> combinations of possible interactions, and constantly check for support
> of specific features instead of just comparing a version number.
>
> Sure, it can be necessary to distinguish between different types of
> nodes, but there is no need to make it this fine-grained.
It's less of a problem in a (nearly) stateless protocol like Bitcoin.
I like the idea of a capabilities command; as time goes on and the ecosystem
of thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search-
blockchain/memory-pool-query clients becomes more varied, it's going to be
more an more important. The particular example that occurs is thin clients
connecting to the network are going to want to ensure they are connected to
at least one non-thin client.
Andy
--
Dr Andy Parkins
andyparkins@gmail•com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
2012-06-16 1:34 ` Amir Taaki
2012-06-16 6:45 ` Wladimir
@ 2012-06-16 8:17 ` Andy Parkins
1 sibling, 0 replies; 11+ messages in thread
From: Andy Parkins @ 2012-06-16 8:17 UTC (permalink / raw)
To: bitcoin-development, Amir Taaki
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. So why not make
the change be simply: one of the service bits indicates that "getcmds" is
available?
Then the version message doesn't need any on-the-wire change.
Andy
--
Dr Andy Parkins
andyparkins@gmail•com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
2012-06-16 8:16 ` Andy Parkins
@ 2012-06-16 8:42 ` Wladimir
2012-06-16 9:16 ` Amir Taaki
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Wladimir @ 2012-06-16 8:42 UTC (permalink / raw)
To: Andy Parkins; +Cc: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]
On Sat, Jun 16, 2012 at 10:16 AM, Andy Parkins <andyparkins@gmail•com>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-specific filters.
I like the idea of a capabilities command; as time goes on and the ecosystem
> of thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search-
> blockchain/memory-pool-query clients becomes more varied, it's going to be
> more an more important. The particular example that occurs is thin clients
> connecting to the network are going to want to ensure they are connected to
> at least one non-thin client.
>
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 protocol.
This also makes it easier to deprecate (lack of) certain features later on.
You can simply drop support for protocol versions before a certain number
(which has happened before). With the extension system this is much harder,
which likely means you keep certain workarounds forever.
Letting the node know of each others capabilities at connection time helps
somewhat. It'd allow refusing clients that do not implement a certain
feature. Then again, to me it's unclear what this wins compared to
incremental protocol versions with clear requirements.
I'm just afraid that the currently simple P2P protocol will turn into a zoo
of complicated (and potentially buggy/insecure) interactions.
So maybe a capability system is a good idea but then the granularity should
be large, not command-level. The interaction between protocol versions and
capabilities needs to be defined as well. Does offering "getdata" at
protocol version 10 mean the same as offering it at protocol version 11"?
Probably not guaranteed. The arguments might have changed. So it's not
entirely self-documenting either.
Wladimir
[-- Attachment #2: Type: text/html, Size: 2772 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
2012-06-16 8:42 ` Wladimir
@ 2012-06-16 9:16 ` Amir Taaki
2012-06-16 9:54 ` Andy Parkins
2012-06-17 15:19 ` Jeff Garzik
2 siblings, 0 replies; 11+ messages in thread
From: Amir Taaki @ 2012-06-16 9:16 UTC (permalink / raw)
To: bitcoin-development
> I'm just afraid that the currently simple P2P protocol will turn into a
zoo of complicated (and potentially buggy/insecure) interactions.
This is my biggest fear too. I would rather be extremely conservative in making any changes to the protocol unless absolutely needed. That includes the bloom filters which take away the fact that Bitcoin is stateless.
I was discussing this with another developer who mentioned something interesting: that always in the lifecycle of system's development, you see increasing complexity during its initial lifecycle as the field is being explored. At some later point, the technology matures and becomes standardised. At that point enough is known that the system snaps together and the cruft can be cut away to reduce the system down to core principles.
It's an interesting viewpoint to consider. I do however advise erring on the side of caution. Maybe there needs to a minimum schedule time before a new extension can be added to the protocol (except security fixes). If we're not careful, the protocol will become enormously huge and kludgy. However maybe as that developer pointed out, trying to stall the inevitable is slowing the long-term evolution of Bitcoin down.
________________________________
From: Wladimir <laanwj@gmail•com>
To: Andy Parkins <andyparkins@gmail•com>
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, cmdlist
On Sat, Jun 16, 2012 at 10:16 AM, Andy Parkins <andyparkins@gmail•com> 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-specific filters.
I like the idea of a capabilities command; as time goes on and the ecosystem
>of thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search-
>blockchain/memory-pool-query clients becomes more varied, it's going to be
>more an more important. The particular example that occurs is thin clients
>connecting to the network are going to want to ensure they are connected to
>at least one non-thin client.
>
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 protocol.
This also makes it easier to deprecate (lack of) certain features later on. You can simply drop support for protocol versions before a certain number (which has happened before). With the extension system this is much harder, which likely means you keep certain workarounds forever.
Letting the node know of each others capabilities at connection time helps somewhat. It'd allow refusing clients that do not implement a certain feature. Then again, to me it's unclear what this wins compared to incremental protocol versions with clear requirements.
I'm just afraid that the currently simple P2P protocol will turn into a zoo of complicated (and potentially buggy/insecure) interactions.
So maybe a capability system is a good idea but then the granularity should be large, not command-level. The interaction between protocol versions and capabilities needs to be defined as well. Does offering "getdata" at protocol version 10 mean the same as offering it at protocol version 11"? Probably not guaranteed. The arguments might have changed. So it's not entirely self-documenting either.
Wladimir
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
2012-06-16 8:42 ` Wladimir
2012-06-16 9:16 ` Amir Taaki
@ 2012-06-16 9:54 ` Andy Parkins
2012-06-17 15:19 ` Jeff Garzik
2 siblings, 0 replies; 11+ messages in thread
From: Andy Parkins @ 2012-06-16 9:54 UTC (permalink / raw)
To: Wladimir; +Cc: bitcoin-development
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 protocol.
My problem is that that I suspect the spectrum of clients will be far more
than simply "thin" or "thick". What about thick-pruned, thick-full? What
about thin-blocks-on-demand and thin-headers-on-demand? These are just what
I can think of now; it seems unwise to limit the functionality of clients
not yet designed with a binary designation. So... we make a field that can
hold more than just a bit; with each possible value representing a specific
(possibly overlapping) set of features? Why not just enumerate the features
then?
I did write responses to each of your following points; but they just
sounded like me being contrary. The short version is that I think too much
emphasis is being placed on defining a specific set of feature->version
mapping. That's going to make it hard for future clients that want to
implement some of the features but not all, and yet still want to be good
bitcoin citizens and be able to tell their peers what they don't support.
For example, there is no easy way for a node to tell another that it doesn't
have the whole block chain available, so requesting it from it will fail.
> I'm just afraid that the currently simple P2P protocol will turn into a
> zoo of complicated (and potentially buggy/insecure) interactions.
Fair enough.
> So maybe a capability system is a good idea but then the granularity
> should be large, not command-level. The interaction between protocol
> versions and capabilities needs to be defined as well. Does offering
> "getdata" at protocol version 10 mean the same as offering it at
> protocol version 11"? Probably not guaranteed. The arguments might have
> changed. So it's not entirely self-documenting either.
That problem doesn't go away just because you don't have a capabilities
system. Either version 11 can speak version 10 or it can't. I don't see
how having a system for finding out that fact changes anything other than
removing a load of protocol noise.
"I support getdata10" makes it far easier to discover that the peer supports
getdata10 than sending getdata11 and watching it fail does.
Andy
--
Dr Andy Parkins
andyparkins@gmail•com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
2012-06-16 8:42 ` Wladimir
2012-06-16 9:16 ` Amir Taaki
2012-06-16 9:54 ` Andy Parkins
@ 2012-06-17 15:19 ` Jeff Garzik
2012-06-17 16:30 ` Amir Taaki
2 siblings, 1 reply; 11+ messages in thread
From: Jeff Garzik @ 2012-06-17 15:19 UTC (permalink / raw)
To: Wladimir; +Cc: bitcoin-development
On Sat, Jun 16, 2012 at 4:42 AM, Wladimir <laanwj@gmail•com> 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 protocol.
>
> This also makes it easier to deprecate (lack of) certain features later on.
> You can simply drop support for protocol versions before a certain number
> (which has happened before). With the extension system this is much harder,
> which likely means you keep certain workarounds forever.
>
> Letting the node know of each others capabilities at connection time helps
> somewhat. It'd allow refusing clients that do not implement a certain
> feature. Then again, to me it's unclear what this wins compared to
> incremental protocol versions with clear requirements.
>
> I'm just afraid that the currently simple P2P protocol will turn into a zoo
> of complicated (and potentially buggy/insecure) interactions.
What is missing here is some perspective on the current situation. It
is -very- easy to make a protocol change and bump PROTOCOL_VERSION in
the Satoshi client.
But for anyone maintaining a non-Satoshi codebase, the P2P protocol is
already filled with all sorts of magic numbers, arbitrarily versioned
binary data structures.. already an unfriendly zoo of complicated and
potentially buggy interactions. There is scant, incomplete
documentation on the wiki -- the Satoshi source code is really the
only true reference.
I see these problems personally, trying to keep ArtForz' half-a-node
running on mainnet (distributed as 'blkmond' with pushpool).
In an era of HTTP and JSON, NFS and iSCSI, bitcoin's P2P protocol is
woefully backwards, fragile, limited and inflexible when it comes to
parameter/extension exchange and negotiation. Even iSCSI, that which
is implemented on hard drive firmware, has the ability to exchange
key=value parameters between local and remote sides of the RPC
connection.
Calling the current P2P protocol "simple" belies all the
implementation details you absolutely -must- get right, to run on
mainnet today. Satoshi client devs almost never see the fragility and
complexity inherent in the current legacy codebase, built up over
time.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
2012-06-17 15:19 ` Jeff Garzik
@ 2012-06-17 16:30 ` Amir Taaki
2012-06-18 1:27 ` Mark Friedenbach
0 siblings, 1 reply; 11+ messages in thread
From: Amir Taaki @ 2012-06-17 16:30 UTC (permalink / raw)
To: bitcoin-development
As the only person to have created and maintaining a full reimplementation of the Bitcoin protocol/standard, I do think Bitcoin is filled with arbitrary endianness and magic numbers. However it is a tiny and simple protocol.
The big problem is not implementing the Bitcoin protocol, but the fact that once you have created a codebase, you want to perfect and fine-tune the design. During the meantime, the Bitcoin protocol is being changed. Change to the Bitcoin protocol is far more damaging to people that want to implement the protocol than any issues with the current protocol.
That's not to say, I disagree with changes to the protocol. I think changes should be a lot more conservative and have a longer time frame than they do currently. Usually changes suddenly get added to the Satoshi client and I notice them in the commit log or announcements. Then it's like "oh I have to add this" and I spend a week working to implement the change without proper consideration or reflection which ends up with me having to compromise on design choices. That is to remain compatible with the protocol.
However it is not my intent to slow down progress so I usually try to hedge against that kind of feeling towards conservatism.
----- Original Message -----
From: Jeff Garzik <jgarzik@exmulti•com>
To: Wladimir <laanwj@gmail•com>
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
On Sat, Jun 16, 2012 at 4:42 AM, Wladimir <laanwj@gmail•com> 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 protocol.
>
> This also makes it easier to deprecate (lack of) certain features later on.
> You can simply drop support for protocol versions before a certain number
> (which has happened before). With the extension system this is much harder,
> which likely means you keep certain workarounds forever.
>
> Letting the node know of each others capabilities at connection time helps
> somewhat. It'd allow refusing clients that do not implement a certain
> feature. Then again, to me it's unclear what this wins compared to
> incremental protocol versions with clear requirements.
>
> I'm just afraid that the currently simple P2P protocol will turn into a zoo
> of complicated (and potentially buggy/insecure) interactions.
What is missing here is some perspective on the current situation. It
is -very- easy to make a protocol change and bump PROTOCOL_VERSION in
the Satoshi client.
But for anyone maintaining a non-Satoshi codebase, the P2P protocol is
already filled with all sorts of magic numbers, arbitrarily versioned
binary data structures.. already an unfriendly zoo of complicated and
potentially buggy interactions. There is scant, incomplete
documentation on the wiki -- the Satoshi source code is really the
only true reference.
I see these problems personally, trying to keep ArtForz' half-a-node
running on mainnet (distributed as 'blkmond' with pushpool).
In an era of HTTP and JSON, NFS and iSCSI, bitcoin's P2P protocol is
woefully backwards, fragile, limited and inflexible when it comes to
parameter/extension exchange and negotiation. Even iSCSI, that which
is implemented on hard drive firmware, has the ability to exchange
key=value parameters between local and remote sides of the RPC
connection.
Calling the current P2P protocol "simple" belies all the
implementation details you absolutely -must- get right, to run on
mainnet today. Satoshi client devs almost never see the fragility and
complexity inherent in the current legacy codebase, built up over
time.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists•sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
2012-06-17 16:30 ` Amir Taaki
@ 2012-06-18 1:27 ` Mark Friedenbach
0 siblings, 0 replies; 11+ messages in thread
From: Mark Friedenbach @ 2012-06-18 1:27 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 6605 bytes --]
Sorry for the duplication Amir, I meant to send this to everyone:
BitTorrent might be an example to look to here. It's a peer-to-peer network
that has undergone many significant protocol upgrades over the years while
maintaining compatibility. More recent clients have had the ability to
expose the capabilities of connected peers and modify behavior accordingly,
and overall it has worked very well.
Capability-based systems do work, and provide an excellent means of trying
out new algorithms, adding new features for upgraded clients, and when
necessary reverting protocol changes (by depreciating or removing
extensions).
The problem with OpenGL was and continues to be that the two superpowers of
that industry develop and maintain competing proposals for similar
functionality, which are thrust upon developers which must support both if
they want access to the latest and greatest features, until such time that
the ARB arbitrarily choses one to standardize upon (in the process creating
yet another extension of the form ARB_* that may be different and must be
explicitly supported by developers).
I think the BitTorrent example shows that a loosely organized, open-source
community *can* maintain a capability-based extension system without
falling into capability-hell.
Mark
On Sun, Jun 17, 2012 at 9:30 AM, Amir Taaki <zgenjix@yahoo•com> wrote:
> As the only person to have created and maintaining a full reimplementation
> of the Bitcoin protocol/standard, I do think Bitcoin is filled with
> arbitrary endianness and magic numbers. However it is a tiny and simple
> protocol.
>
> The big problem is not implementing the Bitcoin protocol, but the fact
> that once you have created a codebase, you want to perfect and fine-tune
> the design. During the meantime, the Bitcoin protocol is being changed.
> Change to the Bitcoin protocol is far more damaging to people that want to
> implement the protocol than any issues with the current protocol.
>
> That's not to say, I disagree with changes to the protocol. I think
> changes should be a lot more conservative and have a longer time frame than
> they do currently. Usually changes suddenly get added to the Satoshi client
> and I notice them in the commit log or announcements. Then it's like "oh I
> have to add this" and I spend a week working to implement the change
> without proper consideration or reflection which ends up with me having to
> compromise on design choices. That is to remain compatible with the
> protocol.
>
> However it is not my intent to slow down progress so I usually try to
> hedge against that kind of feeling towards conservatism.
>
>
>
> ----- Original Message -----
> From: Jeff Garzik <jgarzik@exmulti•com>
> To: Wladimir <laanwj@gmail•com>
> 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
>
> On Sat, Jun 16, 2012 at 4:42 AM, Wladimir <laanwj@gmail•com> 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 protocol.
> >
> > This also makes it easier to deprecate (lack of) certain features later
> on.
> > You can simply drop support for protocol versions before a certain number
> > (which has happened before). With the extension system this is much
> harder,
> > which likely means you keep certain workarounds forever.
> >
> > Letting the node know of each others capabilities at connection time
> helps
> > somewhat. It'd allow refusing clients that do not implement a certain
> > feature. Then again, to me it's unclear what this wins compared to
> > incremental protocol versions with clear requirements.
> >
> > I'm just afraid that the currently simple P2P protocol will turn into a
> zoo
> > of complicated (and potentially buggy/insecure) interactions.
>
> What is missing here is some perspective on the current situation. It
> is -very- easy to make a protocol change and bump PROTOCOL_VERSION in
> the Satoshi client.
>
> But for anyone maintaining a non-Satoshi codebase, the P2P protocol is
> already filled with all sorts of magic numbers, arbitrarily versioned
> binary data structures.. already an unfriendly zoo of complicated and
> potentially buggy interactions. There is scant, incomplete
> documentation on the wiki -- the Satoshi source code is really the
> only true reference.
>
> I see these problems personally, trying to keep ArtForz' half-a-node
> running on mainnet (distributed as 'blkmond' with pushpool).
>
> In an era of HTTP and JSON, NFS and iSCSI, bitcoin's P2P protocol is
> woefully backwards, fragile, limited and inflexible when it comes to
> parameter/extension exchange and negotiation. Even iSCSI, that which
> is implemented on hard drive firmware, has the ability to exchange
> key=value parameters between local and remote sides of the RPC
> connection.
>
> Calling the current P2P protocol "simple" belies all the
> implementation details you absolutely -must- get right, to run on
> mainnet today. Satoshi client devs almost never see the fragility and
> complexity inherent in the current legacy codebase, built up over
> time.
>
> --
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti•com
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 8498 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2012-06-18 1:51 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-16 0:13 [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist Jeff Garzik
2012-06-16 1:34 ` Amir Taaki
2012-06-16 6:45 ` Wladimir
2012-06-16 8:16 ` Andy Parkins
2012-06-16 8:42 ` Wladimir
2012-06-16 9:16 ` Amir Taaki
2012-06-16 9:54 ` Andy Parkins
2012-06-17 15:19 ` Jeff Garzik
2012-06-17 16:30 ` Amir Taaki
2012-06-18 1:27 ` Mark Friedenbach
2012-06-16 8:17 ` Andy Parkins
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox