From: slush <slush@centrum•cz>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed BIP 70 extension
Date: Wed, 25 Jun 2014 16:15:01 +0200 [thread overview]
Message-ID: <CAJna-HiRChr4M9QL_7ZeKQeV7m5M4-ysnERB1DmK1itJMaGucQ@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP0ce4MMX2hOhcGVWt23L_CMn6Cmj9_Okqd0BR9seQXJew@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]
On Wed, Jun 25, 2014 at 10:25 AM, Mike Hearn <mike@plan99•net> wrote:
>
> The protocol is there to contain features! There is zero benefit to
> slavishly following some religious notion of purity or minimalism here.
>
Good standard must be explicit as much as possible. Having million optional
fields with ambiguous meaning is even worse than not having these fields.
HTTP status codes are good example. There are hundreds of them, still
applications understands just few of them, because other have ambiguous
meaning and software don't know how to handle them.
Good example of such over-engineering is also XMPP. XMPP has milions
extensions and features, but look at Jabber clients; call yourself lucky
when you can send messages and files, although there're various extensions
like searching for contacts (something which has be working in ICQ decade
ago), voice support, end to end encryption or alerting users. These
features are defined, but not widely implemented, because its definition is
vague or the feature is abused because of poor design.
Please don't over-engineer payment protocol.
Thank you for your attention.
slush
[-- Attachment #2: Type: text/html, Size: 1707 bytes --]
next prev parent reply other threads:[~2014-06-25 14:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-24 13:27 Mike Hearn
2014-06-24 14:21 ` Jeff Garzik
2014-06-24 14:24 ` Mike Hearn
2014-06-24 14:32 ` slush
2014-06-24 15:06 ` Mike Hearn
2014-06-24 15:15 ` Gmail
2014-06-24 15:48 ` Jeff Garzik
2014-06-24 19:00 ` Gmail
2014-06-24 19:34 ` Andy Alness
2014-06-24 20:12 ` Gavin Andresen
2014-06-24 20:28 ` Gmail
2014-06-25 8:25 ` Mike Hearn
2014-06-25 13:33 ` Jorge Timón
2014-06-25 18:10 ` Jeff Garzik
2014-06-25 14:15 ` slush [this message]
2014-06-25 16:03 ` Gmail
2014-06-24 18:34 ` Roy Badami
2014-06-24 15:43 ` Andreas Schildbach
2014-06-24 15:59 ` Mike Hearn
2014-06-24 17:37 ` Drak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJna-HiRChr4M9QL_7ZeKQeV7m5M4-ysnERB1DmK1itJMaGucQ@mail.gmail.com \
--to=slush@centrum$(echo .)cz \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox