* [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 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
* 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
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