1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <zgenjix@yahoo.com>) id 1Sfp7l-0004Ih-QM
for bitcoin-development@lists.sourceforge.net;
Sat, 16 Jun 2012 09:16:53 +0000
X-ACL-Warn:
Received: from nm31-vm5.bullet.mail.ne1.yahoo.com ([98.138.229.45])
by sog-mx-2.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1Sfp7k-0008I2-Me for bitcoin-development@lists.sourceforge.net;
Sat, 16 Jun 2012 09:16:53 +0000
Received: from [98.138.90.55] by nm31.bullet.mail.ne1.yahoo.com with NNFMP;
16 Jun 2012 09:16:47 -0000
Received: from [98.138.89.194] by tm8.bullet.mail.ne1.yahoo.com with NNFMP;
16 Jun 2012 09:16:46 -0000
Received: from [127.0.0.1] by omp1052.mail.ne1.yahoo.com with NNFMP;
16 Jun 2012 09:16:46 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 842119.36821.bm@omp1052.mail.ne1.yahoo.com
Received: (qmail 41015 invoked by uid 60001); 16 Jun 2012 09:16:46 -0000
X-YMail-OSG: dY9sGQsVM1myGvAiwiUXYDM6zGEqj0kulTVsxp8gWPnX0Ka
WqgXOCLING_vueX6bAR0tA_uVxvIvMu..CSna8.KXfE7KsxreO9XuVTr4S.Y
dsgRLEreg3WJAElKbdkz_dVRwW3O5D331.OaJr9y8Ny2dw256qWt92eMYEu9
W_an63GIE1R_4oCRMR9nf2FTMj3c1U.l1ZHOwg8ehIeMWx9b3vFrgfRIm.ME
j.Cpv_sayNPlos74nEziMO8svUhXxucC8H55ymYxQfxvkQ0zHFNyNfusdbqF
SlXYJSxumWI1Whqjy_E8erixN77sdYtnGnNAVqkwic7vcf_uvGph4JD38Oe1
BcXRRfl1sraDy5KTo_rwc8jYrIh9MLRESoZ3j4KezLNhGtaPi5I5q6KuMRk4
TNUrlpbphq6VcP.hpWG6J51tuots4jHayaJN3jwPFuqEaCeB2b1ybfNPProl
_cCf7uAxFx4t5AH7dlFewnrvK.Db_cD_h.d0MOGB5RLR.a9DaRBhShpKc4Rs
Ckj11.AKhEw--
Received: from [178.5.23.109] by web121005.mail.ne1.yahoo.com via HTTP;
Sat, 16 Jun 2012 02:16:46 PDT
X-Mailer: YahooMailWebService/0.8.118.349524
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
X-Spam-Score: -0.1 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [98.138.229.45 listed in list.dnswl.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(zgenjix[at]yahoo.com)
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 FSL_FREEMAIL_2 FSL_FREEMAIL_2
0.0 FSL_FREEMAIL_1 FSL_FREEMAIL_1
X-Headers-End: 1Sfp7k-0008I2-Me
Subject: Re: [Bitcoin-development] Proposed new P2P command and response:
getcmds, cmdlist
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Amir Taaki <zgenjix@yahoo.com>
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 16 Jun 2012 09:16:53 -0000
> 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
|
