References: <CA+8xBpdD31koaVBh1RuDZKH1sygr8z10K=bPz8DepqYOa8i6yg@mail.gmail.com>
	<1339810493.15660.YahooMailNeo@web121004.mail.ne1.yahoo.com>
	<CA+s+GJCKSrJv4L=4Nj4Hs+j2vfM-oWe5ayD_4NOUJMoXCkm3iA@mail.gmail.com>
	<201206160916.24485.andyparkins@gmail.com>
	<CA+s+GJA2-+HuRFfX3b=-4wv7u9iFCnfOMyDKwekxmipszt27Cw@mail.gmail.com>
	<CA+8xBpcvLsc+UyMT2LjrcuPf2Q+Rp8FQEZFKWddOxwyie0azkw@mail.gmail.com>
Message-ID: <1339950641.22050.YahooMailNeo@web121005.mail.ne1.yahoo.com>
Date: Sun, 17 Jun 2012 09:30:41 -0700 (PDT)
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <CA+8xBpcvLsc+UyMT2LjrcuPf2Q+Rp8FQEZFKWddOxwyie0azkw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Bitcoin-development] Proposed new P2P command and response:
	getcmds, cmdlist
Precedence: list
Reply-To: Amir Taaki <zgenjix@yahoo.com>

As the only person to have created and maintaining a full reimplementation =
of the Bitcoin protocol/standard, I do think Bitcoin is filled with arbitra=
ry endianness and magic numbers. However it is a tiny and simple protocol.=
=0A=0AThe big problem is not implementing the Bitcoin protocol, but the fac=
t 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. Cha=
nge to the Bitcoin protocol is far more damaging to people that want to imp=
lement the protocol than any issues with the current protocol.=0A=0AThat'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 curre=
ntly. 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 con=
sideration or reflection which ends up with me having to compromise on desi=
gn choices. That is to remain compatible with the protocol.=0A=0AHowever it=
 is not my intent to slow down progress so I usually try to hedge against t=
hat kind of feeling towards conservatism.=0A=0A=0A=0A----- Original Message=
 -----=0AFrom: Jeff Garzik <jgarzik@exmulti.com>=0ATo: Wladimir <laanwj@gma=
il.com>=0ACc: bitcoin-development@lists.sourceforge.net=0ASent: Sunday, Jun=
e 17, 2012 5:19 PM=0ASubject: Re: [Bitcoin-development] Proposed new P2P co=
mmand and response: getcmds, cmdlist=0A=0AOn Sat, Jun 16, 2012 at 4:42 AM, =
Wladimir <laanwj@gmail.com> wrote:=0A> Which is a perfectly reasonable requ=
irement. However, one could simply=0A> standardize what a 'thin client' and=
 what a 'thick client' does and offers=0A> (at a certain version level), wi=
thout having to explicitly enumerate=0A> everything over the protocol.=0A>=
=0A> This also makes it easier to deprecate (lack of) certain features late=
r on.=0A> You can simply drop support for protocol versions before a certai=
n number=0A> (which has happened before). With the extension system this is=
 much harder,=0A> which likely means you keep certain workarounds forever.=
=0A>=0A> Letting the node know of each others capabilities at connection ti=
me helps=0A> somewhat. It'd allow refusing clients that do not implement a =
certain=0A> feature. Then again, to me it's unclear what this wins compared=
 to=0A> incremental protocol versions with clear requirements.=0A>=0A> I'm =
just afraid that the currently simple P2P protocol will turn into a zoo=0A>=
 of complicated (and potentially buggy/insecure) interactions.=0A=0AWhat is=
 missing here is some perspective on the current situation.=A0 It=0Ais -ver=
y- easy to make a protocol change and bump PROTOCOL_VERSION in=0Athe Satosh=
i client.=0A=0ABut for anyone maintaining a non-Satoshi codebase, the P2P p=
rotocol is=0Aalready filled with all sorts of magic numbers, arbitrarily ve=
rsioned=0Abinary data structures..=A0 already an unfriendly zoo of complica=
ted and=0Apotentially buggy interactions.=A0 There is scant, incomplete=0Ad=
ocumentation on the wiki -- the Satoshi source code is really the=0Aonly tr=
ue reference.=0A=0AI see these problems personally, trying to keep ArtForz'=
 half-a-node=0Arunning on mainnet (distributed as 'blkmond' with pushpool).=
=0A=0AIn an era of HTTP and JSON, NFS and iSCSI, bitcoin's P2P protocol is=
=0Awoefully backwards, fragile, limited and inflexible when it comes to=0Ap=
arameter/extension exchange and negotiation.=A0 Even iSCSI, that which=0Ais=
 implemented on hard drive firmware, has the ability to exchange=0Akey=3Dva=
lue=A0 parameters between local and remote sides of the RPC=0Aconnection.=
=0A=0ACalling the current P2P protocol "simple" belies all the=0Aimplementa=
tion details you absolutely -must- get right, to run on=0Amainnet today.=A0=
 Satoshi client devs almost never see the fragility and=0Acomplexity inhere=
nt in the current legacy codebase, built up over=0Atime.=0A=0A-- =0AJeff Ga=
rzik=0AexMULTI, Inc.=0Ajgarzik@exmulti.com=0A=0A---------------------------=
---------------------------------------------------=0ALive Security Virtual=
 Conference=0AExclusive live event will cover all the ways today's security=
 and =0Athreat landscape has changed and how IT managers can respond. Discu=
ssions =0Awill include endpoint security, mobile security and the latest in=
 malware =0Athreats. http://www.accelacomm.com/jaw/sfrnl04242012/114/501222=
63/=0A_______________________________________________=0ABitcoin-development=
 mailing list=0ABitcoin-development@lists.sourceforge.net=0Ahttps://lists.s=
ourceforge.net/lists/listinfo/bitcoin-development=0A