Subject: Re: [Bitcoin-development] Change to multiple executables?

From: Pieter Wuille <[email-masked]>
Date: Thu, 11 Aug 2011 15:08:45 +0200

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