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
141
142
143
144
145
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <zgenjix@yahoo.com>) id 1SgINE-0000YM-Qg
for bitcoin-development@lists.sourceforge.net;
Sun, 17 Jun 2012 16:30:48 +0000
X-ACL-Warn:
Received: from nm26-vm3.bullet.mail.ne1.yahoo.com ([98.138.91.156])
by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1SgIND-0004fw-Ms for bitcoin-development@lists.sourceforge.net;
Sun, 17 Jun 2012 16:30:48 +0000
Received: from [98.138.90.56] by nm26.bullet.mail.ne1.yahoo.com with NNFMP;
17 Jun 2012 16:30:41 -0000
Received: from [98.138.89.161] by tm9.bullet.mail.ne1.yahoo.com with NNFMP;
17 Jun 2012 16:30:41 -0000
Received: from [127.0.0.1] by omp1017.mail.ne1.yahoo.com with NNFMP;
17 Jun 2012 16:30:41 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 921637.73904.bm@omp1017.mail.ne1.yahoo.com
Received: (qmail 73973 invoked by uid 60001); 17 Jun 2012 16:30:41 -0000
X-YMail-OSG: 7N_shhkVM1kmzN3c_UeSTo3WrjL.Cb_igDKKebN8quXF5vD
zZ_5HE5b5e0XvcQqV9alOw8QnQE875cRigVtkdbh9zaqA3PhV3.UeFnPUtth
jFAcLRVxWIyTQfl0ln91JQdwW5xICnlTQhE8PPRPbHsidpQ_lBV9TYBJs4WV
JN3R_SaKaAWywXzxlTq7Z.bHDFDirrNM.zEvrmpcIqGhxrBXwXaQKzQyYa.7
qoe1D22LgMS8mDNUzB4DfVVFPPTrZjxxeciXEpnRHArFFEIp5JGIErSNtYMp
On9jnB6rjUo16ZAm88kmtry9XzcqsfygMTGNSqhdlyw3eVHjKy6OiRrP6vve
De.zw4k.kb1qAGSKvP7bhKgI.FzfozByXUEv8zmtaZTju.7x6ZlBpEjLllcu
4JEKXMsLpOQcCelW_iBfWf67RZ5qqQIFm3ARhDpN1.WrVbEKWIfDEg_tmuN7
dwc5mkWlNe.qmlNNp9QLiJ03JUXuz.IvF_xpUPIc2.LQbWjKfJMtIzp5pQt.
Fh0vJ1Ejhjg--
Received: from [77.87.48.248] by web121005.mail.ne1.yahoo.com via HTTP;
Sun, 17 Jun 2012 09:30:41 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>
<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
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.91.156 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: 1SgIND-0004fw-Ms
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: Sun, 17 Jun 2012 16:30:48 -0000
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
|
