From: Pieter Wuille <pieter.wuille@gmail•com>
To: John Smith <witchspace81@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Change to multiple executables?
Date: Thu, 11 Aug 2011 15:08:45 +0200 [thread overview]
Message-ID: <20110811130844.GA24003@ulyssis.org> (raw)
In-Reply-To: <CAJNQ0st4tp83=Dov5phi24jA+4h+qcbgRRTnkRVa00ys_LV+YA@mail.gmail.com>
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
next prev parent reply other threads:[~2011-08-11 13:08 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-10 9:36 John Smith
2011-08-10 10:14 ` Matt Corallo
2011-08-10 10:26 ` John Smith
2011-08-10 10:43 ` Pieter Wuille
[not found] ` <CAJNQ0ssWeU2vgR8XmCyGiZ3UHPv=zjLZEKVM=gqP0ozSC7Wmiw@mail.gmail.com>
2011-08-10 13:18 ` John Smith
2011-08-10 16:49 ` Gavin Andresen
2011-08-10 17:45 ` John Smith
2011-08-10 18:41 ` Gavin Andresen
2011-08-10 19:32 ` Andy Parkins
2011-08-10 19:57 ` Jeff Garzik
2011-08-10 21:13 ` Andy Parkins
2011-08-10 21:35 ` Jeff Garzik
2011-08-10 22:38 ` Andy Parkins
2011-08-11 3:20 ` Jeff Garzik
2011-08-11 5:47 ` Andy Parkins
2011-08-11 11:45 ` Joel Joonatan Kaartinen
2011-08-11 12:01 ` Christian Decker
2011-08-11 14:04 ` Andy Parkins
2011-08-11 12:11 ` Mike Hearn
2011-08-11 13:51 ` Andy Parkins
2011-08-11 12:19 ` John Smith
2011-08-11 13:08 ` Pieter Wuille [this message]
2011-08-10 18:43 ` Luke-Jr
2011-08-10 19:48 ` Jeff Garzik
2011-08-10 21:37 ` Jeff Garzik
2011-08-11 13:50 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110811130844.GA24003@ulyssis.org \
--to=pieter.wuille@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=witchspace81@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox