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
|
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 <sipa@ulyssis.org>) id 1QrV0I-0003C8-HZ
for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 13:08:54 +0000
X-ACL-Warn:
Received: from rhcavuit01.kulnet.kuleuven.be ([134.58.240.129]
helo=cavuit01.kulnet.kuleuven.be)
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1QrV0H-0001iX-9A for bitcoin-development@lists.sourceforge.net;
Thu, 11 Aug 2011 13:08:54 +0000
X-KULeuven-Envelope-From: sipa@ulyssis.org
X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5,
autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00,
FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20)
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: A2B331382E7.A7492
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be
[134.58.240.74])
by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id A2B331382E7;
Thu, 11 Aug 2011 15:08:45 +0200 (CEST)
Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be
[193.190.253.235])
by smtps01.kuleuven.be (Postfix) with ESMTP id 6B89431E702;
Thu, 11 Aug 2011 15:08:45 +0200 (CEST)
Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182])
by smtp.ulyssis.org (Postfix) with ESMTP id E5153F8004;
Thu, 11 Aug 2011 15:11:42 +0200 (CEST)
Received: by wop.ulyssis.org (Postfix, from userid 615)
id 704FA87C1B0; Thu, 11 Aug 2011 15:08:45 +0200 (CEST)
Date: Thu, 11 Aug 2011 15:08:45 +0200
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Wuille <pieter.wuille@gmail.com>
To: John Smith <witchspace81@gmail.com>
Message-ID: <20110811130844.GA24003@ulyssis.org>
References: <CAJNQ0sudgAnr9hMUMt8grSNTYswunyNnp25Uzw5t17ucxTBoGA@mail.gmail.com>
<1312971289.3253.6.camel@BMThinkPad.lan.bluematt.me>
<20110810104316.GA30749@ulyssis.org>
<CAJNQ0ssWeU2vgR8XmCyGiZ3UHPv=zjLZEKVM=gqP0ozSC7Wmiw@mail.gmail.com>
<CAJNQ0stkZ=iBCJA7E5+LZToe2MjEJnhqWoiUtLcqTGPygSikiA@mail.gmail.com>
<CABsx9T0Yvssr04AeT3B8+Gj43hV=P0Uw6M0f+NBNygnAyruQ4A@mail.gmail.com>
<CAJNQ0stfYFN2YCGq-be5D-XW+81ZkVVM_jHHonSy2OHsNyN1Cw@mail.gmail.com>
<CABsx9T059A+RtJ-Mc8XCX6m3dyF23WZ5jraBLGt1=hvSGn14kg@mail.gmail.com>
<CAJNQ0st4tp83=Dov5phi24jA+4h+qcbgRRTnkRVa00ys_LV+YA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJNQ0st4tp83=Dov5phi24jA+4h+qcbgRRTnkRVa00ys_LV+YA@mail.gmail.com>
X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QrV0H-0001iX-9A
Cc: Bitcoin Dev <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 13:08:54 -0000
On Thu, Aug 11, 2011 at 12:19:45PM +0000, John Smith wrote:
> > In this particular case, I said I was mildly against it-- if you want
> > me to switch to supporting it, then reassure me you're willing to do
> > ALL the work to make it happen. Send me a list of wiki pages you'll
> > edit to document the change and tell me that you'll be around to help
> > people rewrite their backup scripts.
>
> IMO this should have been your first reply, instead of first discourgaging
> me from doing it. Just make a list of what needs to be done.
>
> But I won't bother anymore... Let's just keep lumping everything in one
> executable. It's the Satoshi way.
I think there are a lot of misunderstandings here. Given your clarification
that you simply wanted to remove the RPC client from the gui/daemon executable,
I'm all for it. If I reread the answers, there is only "mild against" and a "no"
that was based on a partial misunderstanding.
Somehow it seems that many discussions in which some negative remarks were made
just die out, and the person originally suggesting it takes this as a "shot
down". Maybe (and that includes myself) we should be more outspoken about ideas
we do like.
As for the rest of this thread: i think some dev branch (either something
linux-next like, or a separate official branch, or something else) is indeed
very needed. The main tree should definitely be dealt with in a conservative
way, but it's hard to make progress if you know that every patch that does
some internal changes will need many rebasings and maintainance before it's
actually merged and finally tested by some larger user base.
Considering the issue of backward incompatible changes to the protocol: there is
no denying that there are some serious deficiencies now (double sha256 checksums,
the handling of the data being signed) and redundant things (magic bytes, verack).
Yes, it is true that we could change these in the future with a (nBlocks >= X)
test, but that would still mean you carry around both the old and the new code
until at least block height X. Additionally, if you get another (better) idea
that supercedes it somewhere between now and block X, you're still forced to
first switch to the intermediate one, as some clients may not have upgraded...
This is not to say this isn't an option we should consider, but for now, it just
doesn't seem worth the hassle to me. There may come a day where we absolutely
need a change to the protocol, and when we do, maybe it is time to fix all these
"known and agreed upon defficiencies". It's definitely useful to discuss these,
and in the context of "for when we do an incompatible change", no "breaks backward
compatibility!" argument is valid. I'm in favor of wiki page where these are listed,
together with pro and cons.
--
Pieter
|
