📅 Original date posted:2012-06-17
📝 Original message: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 at exmulti.com>
To: Wladimir <laanwj at gmail.com>
Cc: bitcoin-development at 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 at 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 at 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 at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Amir Taaki [ARCHIVE] /
npub1ep…m3rel
2023-06-07 10:15:51
in reply to nevent1q…m6y8
Author Public Key
npub1ep4j5tjp6cd2774hrx96vh845dwqzhe3z7n3a2a9uxdm2dajqpgscm3relPublished at
2023-06-07 10:15:51Event JSON
{
"id": "ffb0110fd7068675d9046e9fa77f6efb99fdc2c1561f2df9658e59c2bdb8cd37",
"pubkey": "c86b2a2e41d61aaf7ab7198ba65cf5a35c015f3117a71eaba5e19bb537b20051",
"created_at": 1686132951,
"kind": 1,
"tags": [
[
"e",
"76f83e7269d7cdc3a12f52c2cf18660afe267f079ced72d533a304a164bd5ac9",
"",
"root"
],
[
"e",
"ba524441bf7df7e25f4ea7a77e0c28faa7548663b75d55637c020ebbbf85cb98",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2012-06-17\n📝 Original message: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.\n\nThe 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.\n\nThat'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.\n\nHowever it is not my intent to slow down progress so I usually try to hedge against that kind of feeling towards conservatism.\n\n\n\n----- Original Message -----\nFrom: Jeff Garzik \u003cjgarzik at exmulti.com\u003e\nTo: Wladimir \u003claanwj at gmail.com\u003e\nCc: bitcoin-development at lists.sourceforge.net\nSent: Sunday, June 17, 2012 5:19 PM\nSubject: Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist\n\nOn Sat, Jun 16, 2012 at 4:42 AM, Wladimir \u003claanwj at gmail.com\u003e wrote:\n\u003e Which is a perfectly reasonable requirement. However, one could simply\n\u003e standardize what a 'thin client' and what a 'thick client' does and offers\n\u003e (at a certain version level), without having to explicitly enumerate\n\u003e everything over the protocol.\n\u003e\n\u003e This also makes it easier to deprecate (lack of) certain features later on.\n\u003e You can simply drop support for protocol versions before a certain number\n\u003e (which has happened before). With the extension system this is much harder,\n\u003e which likely means you keep certain workarounds forever.\n\u003e\n\u003e Letting the node know of each others capabilities at connection time helps\n\u003e somewhat. It'd allow refusing clients that do not implement a certain\n\u003e feature. Then again, to me it's unclear what this wins compared to\n\u003e incremental protocol versions with clear requirements.\n\u003e\n\u003e I'm just afraid that the currently simple P2P protocol will turn into a zoo\n\u003e of complicated (and potentially buggy/insecure) interactions.\n\nWhat is missing here is some perspective on the current situation. It\nis -very- easy to make a protocol change and bump PROTOCOL_VERSION in\nthe Satoshi client.\n\nBut for anyone maintaining a non-Satoshi codebase, the P2P protocol is\nalready filled with all sorts of magic numbers, arbitrarily versioned\nbinary data structures.. already an unfriendly zoo of complicated and\npotentially buggy interactions. There is scant, incomplete\ndocumentation on the wiki -- the Satoshi source code is really the\nonly true reference.\n\nI see these problems personally, trying to keep ArtForz' half-a-node\nrunning on mainnet (distributed as 'blkmond' with pushpool).\n\nIn an era of HTTP and JSON, NFS and iSCSI, bitcoin's P2P protocol is\nwoefully backwards, fragile, limited and inflexible when it comes to\nparameter/extension exchange and negotiation. Even iSCSI, that which\nis implemented on hard drive firmware, has the ability to exchange\nkey=value parameters between local and remote sides of the RPC\nconnection.\n\nCalling the current P2P protocol \"simple\" belies all the\nimplementation details you absolutely -must- get right, to run on\nmainnet today. Satoshi client devs almost never see the fragility and\ncomplexity inherent in the current legacy codebase, built up over\ntime.\n\n-- \nJeff Garzik\nexMULTI, Inc.\njgarzik at exmulti.com\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": "addf199b6a9cd50053e551e8e95ebc7369e6fb365c84a61988fd37dcd46099c5b6d8187351d400680f87d8d71dd021b54c901cb8947516256803c90fd05755f3"
}