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
146
147
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1QrU6p-0008Kv-Ka
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 12:11:35 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.175 as permitted sender)
client-ip=209.85.220.175; envelope-from=mh.in.england@gmail.com;
helo=mail-vx0-f175.google.com;
Received: from mail-vx0-f175.google.com ([209.85.220.175])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QrU6o-0008DG-MV
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 12:11:35 +0000
Received: by vxj14 with SMTP id 14so2315218vxj.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 11 Aug 2011 05:11:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.30.47 with SMTP id p15mr8034243vdh.130.1313064689258; Thu,
11 Aug 2011 05:11:29 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.52.164.165 with HTTP; Thu, 11 Aug 2011 05:11:29 -0700 (PDT)
In-Reply-To: <201108102213.09632.andyparkins@gmail.com>
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
<201108102032.00373.andyparkins@gmail.com>
<CA+8xBpdCtYQkKwQZzZY2PsHm=+BrhD4TdoKqoAVoa7R0W9YkRw@mail.gmail.com>
<201108102213.09632.andyparkins@gmail.com>
Date: Thu, 11 Aug 2011 14:11:29 +0200
X-Google-Sender-Auth: KuRZbBmFGjsdrhCYwUSTe_x09NY
Message-ID: <CANEZrP16NhS=4rqKcqBBqdDzd7XbDR_aXudBeq-_51ddmcLd_w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Andy Parkins <andyparkins@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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.8 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QrU6o-0008DG-MV
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Change to multiple executables?
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: Thu, 11 Aug 2011 12:11:35 -0000
I don't think Gavin misunderstands how open source works at all. It's
completely normal for project maintainers to say "no" more often than
they say "yes". When I worked on open source for a living this was
part of the natural flow of things.
It's important to understand that ideas which receive "maybe" or "yes
but later" or "no unless you convince me" or "perhaps in a different
way" are not being shot down. These answers are requests for more work
to be done. You *cannot* get emotional about open source contributions
and any veteran will tell you this. Open source maintainers cannot and
do not say yes to every patch or idea that is proposed. I would be
very worried if Gavin did.
Now let's review these ideas:
> Don't believe me? =C2=A0Here's a list of ideas
>
> =C2=A0- Extra bits in the service field of the version message to allow n=
odes
> =C2=A0 to indicate if they are mining; if they are willing to be seed nod=
es;
> =C2=A0 if they relay transactions; if they want relayed transactions.
I think the concept is reasonable but service flags might not be the
best way to do it, for instance, asking for a filtered transaction
feed is useful for lightweight clients so you'd want more precision
that can be fit into service bits.
> =C2=A0- getblocks in reverse chronological order so clients can start up =
quicker
> =C2=A0 while downloading the blocks in the backround. =C2=A0Ironically I =
was told
> =C2=A0 "patches welcome" by someone who didn't reject this one instantly.
I already told you this won't help startup time because you have to
connect blocks together in sequence. You can't build up the block
chain backwards unless you don't care about validation at all.
> =C2=A0- Query miners for pending transactions
Or just have them send an inv containing them after connect. I don't
remember this one being "shot down".
> =C2=A0- Application version separate from client version
You mean separate from protocol version, right?
> =C2=A0- A way of requesting block bodies without headers (saving a lot of=
traffic
> =C2=A0 for a thin client upgrading)
The cost/benefit ratio of this one isn't obvious at all. The resource
requirements for running a full node are large enough that
re-downloading 80 bytes per block is the least of your worries if
you're upgrading.
> =C2=A0- Double SHA-256 for a packet checksum? =C2=A0Seriously?
Feel free to submit a patch to disable checksum validation and see if
Gavin accepts it. It needs to still be calculated at send time for
other implementations.
> =C2=A0- Sequence number as part of TxIn instead of part of the whole tran=
saction
Sequence numbers are already part of the tx inputs. Or do you mean
they should be part of the whole transaction? If the latter then this
is indeed an idea that will be shot down, it's deliberate that seqnums
are part of the txinputs and it needs to be that way for contracts. It
can't be changed without forking the protocol anyway.
> Every single one of those has been shot down by one or more of the main
> developers. =C2=A0I'm not a genius, and not arrogant enough to assume tha=
t
> everything I say is right, but _nothing_? =C2=A0Really? =C2=A0There is no=
problem that
> one of the above addresses?
Some of your proposals address problems that need to be solved, but
it's not clear that way is the right way to solve them. Others reflect
either lack of understanding of the system or the fact that you don't
value backwards compatibility whereas other people do.
|
