📅 Original date posted:2011-11-05
🗒️ Summary of this message: Strict adherence to the protocol is necessary for financial transactions. Clients that do not comply should be rejected. A user agent string can be added, but kept separate from the protocol version.
📝 Original message:> If clients break the network protocol/do not comply properly with it,
> they should be disconnected and shunned. Hard love. We don't want any
> ambiguity in the protocol.
> However my feeling about the user-agent string is that it is a vanity
> item, but here we'd be enforcing a format that everybody can
> understand and read.
I agree with Amir completely on both these points.
With something as critical as financial transactions, no exceptions can
be made. The reported client and version should be ignored completely.
If a client does not comply with the protocol, they must be rejected
outright.
It is not in the best interest, or ability, to attempt to micromanage
how developers choose to use the information given. Recommendations and
guidelines can be made, but how they choose to implement is ultimately
their decision. In my opinion, clear and concise definition of the
protocol, and strict adherence in the mainline client, are the best
options available.
The protocol version should be indicated so that it can properly be
handled. Neither the name of the client, or it's version, need to be
reported in this. Protocol validation should ignore this completely.
I do not believe that leaving out the client name and version entirely
is the best option though. As silly as it may seem to some, vanity and
recognition are very strong motivators. We want to encourage more
supporters to the scene, not scare them away. The additional data
provided by this could also be used for calculating various statistics.
It sounds like BitcoinJ and BitDroid have already found ways of adding
it in anyway. I believe it is in the best interest of the developers to
formalize how this information will be included, and use it to their
advantage.
TL;DR: Adhere strictly to the protocol, and reject clients that do not.
Add a user agent string of some kind, but keep it separate from the
protocol version.
Jordan Mack [ARCHIVE] /
npub18y…3txp2
2023-06-07 02:37:39
in reply to nevent1q…vvxd
Author Public Key
npub18yq2ukhtlnkuzzykluyjvxap3vtvdqf0arvtag6rx02klk6gymgqp3txp2Published at
2023-06-07 02:37:39Event JSON
{
"id": "5224c7c7c19b2c4d9b79516a64c619068d0f30d97ce97ec5d9069a8a56a7f096",
"pubkey": "3900ae5aebfcedc10896ff09261ba18b16c6812fe8d8bea34333d56fdb4826d0",
"created_at": 1686105459,
"kind": 1,
"tags": [
[
"e",
"584ae74b575c9742306f580d5f64feda74a51793a9300be5c13870247fc9a7f7",
"",
"root"
],
[
"e",
"d46e8943f0b9a80b1e1dde60a365b5cefed19160e013227c94ff9af4f685d54b",
"",
"reply"
],
[
"p",
"c86b2a2e41d61aaf7ab7198ba65cf5a35c015f3117a71eaba5e19bb537b20051"
]
],
"content": "📅 Original date posted:2011-11-05\n🗒️ Summary of this message: Strict adherence to the protocol is necessary for financial transactions. Clients that do not comply should be rejected. A user agent string can be added, but kept separate from the protocol version.\n📝 Original message:\u003e If clients break the network protocol/do not comply properly with it,\n \u003e they should be disconnected and shunned. Hard love. We don't want any\n \u003e ambiguity in the protocol.\n\n \u003e However my feeling about the user-agent string is that it is a vanity\n \u003e item, but here we'd be enforcing a format that everybody can\n \u003e understand and read.\n\nI agree with Amir completely on both these points.\n\nWith something as critical as financial transactions, no exceptions can \nbe made. The reported client and version should be ignored completely. \nIf a client does not comply with the protocol, they must be rejected \noutright.\n\nIt is not in the best interest, or ability, to attempt to micromanage \nhow developers choose to use the information given. Recommendations and \nguidelines can be made, but how they choose to implement is ultimately \ntheir decision. In my opinion, clear and concise definition of the \nprotocol, and strict adherence in the mainline client, are the best \noptions available.\n\nThe protocol version should be indicated so that it can properly be \nhandled. Neither the name of the client, or it's version, need to be \nreported in this. Protocol validation should ignore this completely.\n\nI do not believe that leaving out the client name and version entirely \nis the best option though. As silly as it may seem to some, vanity and \nrecognition are very strong motivators. We want to encourage more \nsupporters to the scene, not scare them away. The additional data \nprovided by this could also be used for calculating various statistics. \nIt sounds like BitcoinJ and BitDroid have already found ways of adding \nit in anyway. I believe it is in the best interest of the developers to \nformalize how this information will be included, and use it to their \nadvantage.\n\nTL;DR: Adhere strictly to the protocol, and reject clients that do not. \nAdd a user agent string of some kind, but keep it separate from the \nprotocol version.",
"sig": "3c7b11fd37988e5d3cf23e780c15dc66a816fead59d0433e3c85d4c22b30ff222040ee57630b6b940c96f9eaec39c3ef0b19b6a6c9426ae06e92e0a1c9899d6f"
}