📅 Original date posted:2012-06-16
📝 Original message:> 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 at gmail.com>
To: Andy Parkins <andyparkins at gmail.com>
Cc: bitcoin-development at 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 at 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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Amir Taaki [ARCHIVE] /
npub1ep…m3rel
2023-06-07 10:15:42
in reply to nevent1q…vxy2
Author Public Key
npub1ep4j5tjp6cd2774hrx96vh845dwqzhe3z7n3a2a9uxdm2dajqpgscm3relPublished at
2023-06-07 10:15:42Event JSON
{
"id": "7576577ed6d0423e72c1b681df441b8f84d6c98052240c337874e1524e5e505c",
"pubkey": "c86b2a2e41d61aaf7ab7198ba65cf5a35c015f3117a71eaba5e19bb537b20051",
"created_at": 1686132942,
"kind": 1,
"tags": [
[
"e",
"76f83e7269d7cdc3a12f52c2cf18660afe267f079ced72d533a304a164bd5ac9",
"",
"root"
],
[
"e",
"5d68997116ad0ad0415ccd4a02f41cfb65701bf00fb480400b6e9c050d3a0af8",
"",
"reply"
],
[
"p",
"30217b018a47b99ed4c20399b44b02f70ec4f58ed77a2814a563fa28322ef722"
]
],
"content": "📅 Original date posted:2012-06-16\n📝 Original message:\u003e I'm just afraid that the currently simple P2P protocol will turn into a \nzoo of complicated (and potentially buggy/insecure) interactions. \n\n\nThis 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.\n\nI 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.\n\nIt'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.\n\n\n________________________________\nFrom: Wladimir \u003claanwj at gmail.com\u003e\nTo: Andy Parkins \u003candyparkins at gmail.com\u003e \nCc: bitcoin-development at lists.sourceforge.net \nSent: Saturday, June 16, 2012 10:42 AM\nSubject: Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist\n\n\nOn Sat, Jun 16, 2012 at 10:16 AM, Andy Parkins \u003candyparkins at gmail.com\u003e wrote:\n\n\n\u003eIt's less of a problem in a (nearly) stateless protocol like Bitcoin.\n\u003e\n\nIt'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.\n\nI like the idea of a capabilities command; as time goes on and the ecosystem\n\u003eof thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search-\n\u003eblockchain/memory-pool-query clients becomes more varied, it's going to be\n\u003emore an more important. The particular example that occurs is thin clients\n\u003econnecting to the network are going to want to ensure they are connected to\n\u003eat least one non-thin client.\n\u003e\n\nWhich 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. \n\nThis 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. \n\nLetting 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. \n\nI'm just afraid that the currently simple P2P protocol will turn into a zoo of complicated (and potentially buggy/insecure) interactions. \n\nSo 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.\n\nWladimir\n\n------------------------------------------------------------------------------\nLive Security Virtual Conference\nExclusive live event will cover all the ways today's security and \nthreat landscape has changed and how IT managers can respond. Discussions \nwill include endpoint security, mobile security and the latest in malware \nthreats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/\n_______________________________________________\nBitcoin-development mailing list\nBitcoin-development at lists.sourceforge.net\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-development",
"sig": "a9e73d33bceffb2cce1b0990ef1879be5d3e9a02aef7e76f862d050506eda8b7ea73c8e862a2239605d3a627772bbdb1592a4a2b6460d9e4c4cfe7c8ef41dbb6"
}