From: Jeff Garzik <jgarzik@exmulti•com>
To: Andy Parkins <andyparkins@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Change to multiple executables?
Date: Wed, 10 Aug 2011 23:20:25 -0400 [thread overview]
Message-ID: <CA+8xBpdFH0YtkKPP6hKCf3Q2+2+Lzy0hjjaGYt6y8iBDudJuDw@mail.gmail.com> (raw)
In-Reply-To: <201108102338.21680.andyparkins@gmail.com>
On Wed, Aug 10, 2011 at 6:38 PM, Andy Parkins <andyparkins@gmail•com> wrote:
> On Wednesday 10 August 2011 22:35:01 Jeff Garzik wrote:
>
>> On Wed, Aug 10, 2011 at 5:13 PM, Andy Parkins <andyparkins@gmail•com>
> wrote:
>> > Don't believe me? Here's a list of ideas I've had "no, no, no"d so
>> > far; not one of which would have any financial implication at all.
>> > Only some of which would break backward compatibility.
>>
>> Breaking backwards compatibility means breaking people's access to
>> their own money.
>
> I wasn't actually giving a full explanation of how these things could be
> done, I was providing a list of "negatively received ideas"; imagine my
> surprise that they have been negatively received by you.
>
> However... The version number field combined with the massive complexity of:
>
> if( blockNumber > 500000 )
> new_process();
> else
> old_process();
>
> Would sort all of your "compatibility" objections out, and would give nodes
> time to upgrade.
The above has been discussed on the forums. The community seems to
consider that option one of last resort, because the consequences of
-not- upgrading immediately become "I cannot access my money." The
community also seems rather hard-wired against breaking changes like
that, because it implies that we lowly dev peons are daring to mess
with the Blessed Satoshi Design that has received extensive study, and
100% communal agreement.
If the community changes its mind, and there are strong calls to make
a breaking change, we can certainly do that. Bitcoin is not only open
source but very much democratic -- people vote by choosing which
client software to use.
> However, the protocol is being treated as if it is some kind of holy scroll,
> and must not be touched. Bitcoin's ideas are revolutionary, its
> implementation is not. If we started again today, it would be done
> differently. Shouldn't we be trying to move the current protocol toward
> _that_ "done differently" as much as possible while bitcoin is still
> relatively small? Rhetorical again... I know the answer, it's "no".
Historically speaking, the protocol has had minor tweaks, if you check
the patch history. Adding new protocol commands is pretty easy, for
example. Removing commands tends to be high cost for low benefit
("protocol removes a harmless redundancy"), if you're messing with the
initial negotiation sequence. IMO verack is not redundant, anyway.
But the answer is "what do the users want" not "no" At the end of the
day we're here to adequately reflect the needs of our userbase at all.
And so far, the userbase seems highly conservative when it comes to
incompatible changes. Correct me if I'm wrong...
> I disagree about how set in stone these things are; but yeah; I've accepted
> that I'm on a loser. My list was to demonstrate how negative the community
> is; and you have confirmed that for me admirably. Bear that in mind the
> next time you're discussing the lack of manpower for bug fixes.
It's negative to weight costs vs. benefits? That is what I expect any
good engineer to do.
In any case, our -users- are not clamoring for breaking changes of the
type you describe above, as far as I can see. Just the opposite. So
if you want to deploy a breaking change, the burden is on you to
convince the bitcoin users and miners that it's a good idea.
If the bitcoin dev team is not accurately reflecting the desire of its
users, then that should be corrected, and we want to hear feedback.
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
next prev parent reply other threads:[~2011-08-11 3:48 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 [this message]
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
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=CA+8xBpdFH0YtkKPP6hKCf3Q2+2+Lzy0hjjaGYt6y8iBDudJuDw@mail.gmail.com \
--to=jgarzik@exmulti$(echo .)com \
--cc=andyparkins@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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