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 ) 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 To: John Smith Message-ID: <20110811130844.GA24003@ulyssis.org> References: <1312971289.3253.6.camel@BMThinkPad.lan.bluematt.me> <20110810104316.GA30749@ulyssis.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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