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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@exmulti.com>) id 1SgHGj-00083g-FP
for bitcoin-development@lists.sourceforge.net;
Sun, 17 Jun 2012 15:20:01 +0000
X-ACL-Warn:
Received: from mail-lb0-f175.google.com ([209.85.217.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SgHGi-0007h1-Dr
for bitcoin-development@lists.sourceforge.net;
Sun, 17 Jun 2012 15:20:01 +0000
Received: by lbol5 with SMTP id l5so4267023lbo.34
for <bitcoin-development@lists.sourceforge.net>;
Sun, 17 Jun 2012 08:19:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:x-originating-ip:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type:x-gm-message-state;
bh=acsgV7Sa70uS4w4L7c6i7UM2D6MmVg3k8UxJzsre4z4=;
b=KgI0l0LRJRff/CEm4HaEWeexy1eOeGq8RVqF34rWipBWl5t+ve+8LQelNYhEH/ZLyC
oIyoehwAJpsxlyOL2DVf0dXZzL0lzQhMu2W6Zm4QS2xDgBIdquPsd/X25DgrKrg2JNgf
Z1mgBpzQK/cwoE9WKVe/9wloyW3WnI9dlFKgLeKqg9QmXHgfE+YJKfY5uCEoQ70p/rnh
f+Y/kAmLypD2OWpZNa86EmBgyQ842dxcGhzWmK2DCPz9A+0unolxxTOrhF4hjODeBO13
Y6Go1TreFSyjP/uoygg4f8uEgYbQK0K94Dos+/kA8+nflwOFBrjIjFe5mFsXULl6zSO9
GCVQ==
MIME-Version: 1.0
Received: by 10.152.109.198 with SMTP id hu6mr11448047lab.21.1339946393524;
Sun, 17 Jun 2012 08:19:53 -0700 (PDT)
Received: by 10.114.19.70 with HTTP; Sun, 17 Jun 2012 08:19:53 -0700 (PDT)
X-Originating-IP: [2001:4830:1603:2:21c:c0ff:fe79:c8c2]
In-Reply-To: <CA+s+GJA2-+HuRFfX3b=-4wv7u9iFCnfOMyDKwekxmipszt27Cw@mail.gmail.com>
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>
Date: Sun, 17 Jun 2012 11:19:53 -0400
Message-ID: <CA+8xBpcvLsc+UyMT2LjrcuPf2Q+Rp8FQEZFKWddOxwyie0azkw@mail.gmail.com>
From: Jeff Garzik <jgarzik@exmulti.com>
To: Wladimir <laanwj@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQkDeuDCE2tSg/l37V3pr2lo2k60OlPU4Lw8i+2OTzqJp59b+2zB/efoBtx87Z9kl5LKA7iM
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1SgHGi-0007h1-Dr
Cc: bitcoin-development@lists.sourceforge.net
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
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: Sun, 17 Jun 2012 15:20:01 -0000
On Sat, Jun 16, 2012 at 4:42 AM, Wladimir <laanwj@gmail.com> wrote:
> Which is a perfectly reasonable requirement. However, one could simply
> standardize what a 'thin client' and what a 'thick client' does and offers
> (at a certain version level), without having to explicitly enumerate
> everything over the protocol.
>
> This also makes it easier to deprecate (lack of) certain features later on.
> You can simply drop support for protocol versions before a certain number
> (which has happened before). With the extension system this is much harder,
> which likely means you keep certain workarounds forever.
>
> Letting 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.
>
> I'm just afraid that the currently simple P2P protocol will turn into a zoo
> of complicated (and potentially buggy/insecure) interactions.
What is missing here is some perspective on the current situation. It
is -very- easy to make a protocol change and bump PROTOCOL_VERSION in
the Satoshi client.
But for anyone maintaining a non-Satoshi codebase, the P2P protocol is
already filled with all sorts of magic numbers, arbitrarily versioned
binary data structures.. already an unfriendly zoo of complicated and
potentially buggy interactions. There is scant, incomplete
documentation on the wiki -- the Satoshi source code is really the
only true reference.
I see these problems personally, trying to keep ArtForz' half-a-node
running on mainnet (distributed as 'blkmond' with pushpool).
In an era of HTTP and JSON, NFS and iSCSI, bitcoin's P2P protocol is
woefully backwards, fragile, limited and inflexible when it comes to
parameter/extension exchange and negotiation. Even iSCSI, that which
is implemented on hard drive firmware, has the ability to exchange
key=value parameters between local and remote sides of the RPC
connection.
Calling the current P2P protocol "simple" belies all the
implementation details you absolutely -must- get right, to run on
mainnet today. Satoshi client devs almost never see the fragility and
complexity inherent in the current legacy codebase, built up over
time.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti.com
|
