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>
Message-ID: <1339838206.26361.YahooMailNeo@web121005.mail.ne1.yahoo.com>
Date: Sat, 16 Jun 2012 02:16:46 -0700 (PDT)
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <CA+s+GJA2-+HuRFfX3b=-4wv7u9iFCnfOMyDKwekxmipszt27Cw@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>

> I'm just afraid that the currently simple P2P protocol will turn into a =
=0Azoo of complicated (and potentially buggy/insecure) interactions. =0A=0A=
=0AThis 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.=0A=
=0AI was discussing this with another developer who mentioned something int=
eresting: that always in the lifecycle of system's development, you see inc=
reasing complexity during its initial lifecycle as the field is being explo=
red. 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.=0A=0AIt's an =
interesting viewpoint to consider. I do however advise erring on the side o=
f caution. Maybe there needs to a minimum schedule time before a new extens=
ion can be added to the protocol (except security fixes). If we're not care=
ful, the protocol will become enormously huge and kludgy. However maybe as =
that developer pointed out, trying to stall the inevitable is slowing the l=
ong-term evolution of Bitcoin down.=0A=0A=0A_______________________________=
_=0AFrom: Wladimir <laanwj@gmail.com>=0ATo: Andy Parkins <andyparkins@gmail=
.com> =0ACc: bitcoin-development@lists.sourceforge.net =0ASent: Saturday, J=
une 16, 2012 10:42 AM=0ASubject: Re: [Bitcoin-development] Proposed new P2P=
 command and response: getcmds, cmdlist=0A=0A=0AOn Sat, Jun 16, 2012 at 10:=
16 AM, Andy Parkins <andyparkins@gmail.com> wrote:=0A=0A=0A>It's less of a =
problem in a (nearly) stateless protocol like Bitcoin.=0A>=0A=0AIt's curren=
tly (nearly) stateless, however it would be short-sighted to think it will =
stay that way. State is being introduced as we speak; for example, connecti=
on-specific filters.=0A=0AI like the idea of a capabilities command; as tim=
e goes on and the ecosystem=0A>of thin/spv/semi-thin/headers-only/blocks-on=
-demand/reverse-search-=0A>blockchain/memory-pool-query clients becomes mor=
e varied, it's going to be=0A>more an more important. =A0The particular exa=
mple that occurs is thin clients=0A>connecting to the network are going to =
want to ensure they are connected to=0A>at least one non-thin client.=0A>=
=0A=0AWhich is a perfectly reasonable requirement. However, one could simpl=
y standardize what a 'thin client' and what a 'thick client' does and offer=
s (at a certain version level), without having to explicitly enumerate ever=
ything over the protocol.=A0=0A=0AThis also makes it easier to deprecate (l=
ack of) certain features later on. You can simply drop support for protocol=
 versions before a certain number (which has happened before). With the ext=
ension system this is much harder, which likely means you keep certain work=
arounds forever.=A0=0A=0ALetting 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.=A0=0A=0A=
I'm just afraid that the currently simple P2P protocol will turn into a zoo=
 of complicated (and potentially buggy/insecure) interactions.=A0=0A=0ASo m=
aybe a capability system is a good idea but then the granularity should be =
large, not command-level. The interaction between protocol versions and cap=
abilities needs to be defined as well. Does offering "getdata" at protocol =
version 10 mean the same as offering it at protocol version 11"? Probably n=
ot guaranteed. The arguments might have changed. So it's not entirely self-=
documenting either.=0A=0AWladimir=0A=0A------------------------------------=
------------------------------------------=0ALive Security Virtual Conferen=
ce=0AExclusive live event will cover all the ways today's security and =0At=
hreat landscape has changed and how IT managers can respond. Discussions =
=0Awill include endpoint security, mobile security and the latest in malwar=
e =0Athreats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/=0A_=
______________________________________________=0ABitcoin-development mailin=
g list=0ABitcoin-development@lists.sourceforge.net=0Ahttps://lists.sourcefo=
rge.net/lists/listinfo/bitcoin-development