Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-11 🗒️ Summary of this message: A developer ...
📅 Original date posted:2011-08-11
🗒️ Summary of this message: A developer suggests delaying incompatible changes until they have propagated, but the community is hard-wired against breaking changes.
📝 Original message:On Thursday 11 August 2011 04:20:25 Jeff Garzik wrote:
> > 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
Did you even read what I wrote? "if( blockNumber > 5000000 )" is about as
far from immediate as you can get. I'm not an idiot; I understand we can't
lock people out of their money simply because of a software upgrade. It's
not unreasonable to expect people will have upgraded by block 500000 though
(or whatever number the community decided upon).
Again you're missing my point... you are still shooting ideas down.
> 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.
Well the community had better unhardwire itself or its going to end up with
five developers and no more.
> 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.
Voting with ones feet should be a last resort. Wouldn't it be better not to
end up with incompatible clients out there?
> 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.
Client: I speak version 10
Server: hmmm, I don't speak version 10, I only speak version 5
Client: I am willing to lower to version 5 so I shall continue
or
Client: I speak version 10
Server: hmmm, I don't speak version 10, I only speak version 5
Client: I am unwilling to lower to version 5 so I shall hang up
or
Client: I speak version 5
Server: hmmm, I speak version 10, but I am willing to speak version 5
or
Client: I speak version 5
Server: hmmm, I speak version 10, and I am unwilling to speak version 5
so I shall hang up
'verack' is redundant. It sends no information and merely says that the
other end is willing to continue. Willing to continue is easily determined
when the remote continues. Handling 'verack' is an annoyance, and adds
nothing.
> 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...
Please point me at a single incompatible change that has been rejected by
the userbase.
Further: I'm not suggesting incompatible changes alone; that would be
insane. I'm suggesting upgrade paths that delay incompatible changes until
the change has propagated.
> It's negative to weight costs vs. benefits? That is what I expect any
> good engineer to do.
I don't think that's what's happening. Not once have I seen the "benefits"
side of that equation. What I have seen is plenty of "I can't see a use
case for that"; when the key word in that sentence is "I".
> 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.
The users aren't typically going to be familiar enough with the internals of
bitcoin to care about many of the changes I suggested. I have repeatedly
said I don't want to break anything, I want to transition in an orderly
fashion (and the majority of my suggestions were backward compatible). But
of course, I don't actually want to do anything with bitcoind itself, it's
been made repeatedly clear to me that anything I might ask for is not going
to happen -- and of course what I was pointing out, _not_ asking for, was
that you can't expect to get new developers on board if they aren't going to
be allowed to scratch their itches.
> 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.
You've just had some. The response was "you're wrong".
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
🗒️ Summary of this message: A developer suggests delaying incompatible changes until they have propagated, but the community is hard-wired against breaking changes.
📝 Original message:On Thursday 11 August 2011 04:20:25 Jeff Garzik wrote:
> > 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
Did you even read what I wrote? "if( blockNumber > 5000000 )" is about as
far from immediate as you can get. I'm not an idiot; I understand we can't
lock people out of their money simply because of a software upgrade. It's
not unreasonable to expect people will have upgraded by block 500000 though
(or whatever number the community decided upon).
Again you're missing my point... you are still shooting ideas down.
> 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.
Well the community had better unhardwire itself or its going to end up with
five developers and no more.
> 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.
Voting with ones feet should be a last resort. Wouldn't it be better not to
end up with incompatible clients out there?
> 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.
Client: I speak version 10
Server: hmmm, I don't speak version 10, I only speak version 5
Client: I am willing to lower to version 5 so I shall continue
or
Client: I speak version 10
Server: hmmm, I don't speak version 10, I only speak version 5
Client: I am unwilling to lower to version 5 so I shall hang up
or
Client: I speak version 5
Server: hmmm, I speak version 10, but I am willing to speak version 5
or
Client: I speak version 5
Server: hmmm, I speak version 10, and I am unwilling to speak version 5
so I shall hang up
'verack' is redundant. It sends no information and merely says that the
other end is willing to continue. Willing to continue is easily determined
when the remote continues. Handling 'verack' is an annoyance, and adds
nothing.
> 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...
Please point me at a single incompatible change that has been rejected by
the userbase.
Further: I'm not suggesting incompatible changes alone; that would be
insane. I'm suggesting upgrade paths that delay incompatible changes until
the change has propagated.
> It's negative to weight costs vs. benefits? That is what I expect any
> good engineer to do.
I don't think that's what's happening. Not once have I seen the "benefits"
side of that equation. What I have seen is plenty of "I can't see a use
case for that"; when the key word in that sentence is "I".
> 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.
The users aren't typically going to be familiar enough with the internals of
bitcoin to care about many of the changes I suggested. I have repeatedly
said I don't want to break anything, I want to transition in an orderly
fashion (and the majority of my suggestions were backward compatible). But
of course, I don't actually want to do anything with bitcoind itself, it's
been made repeatedly clear to me that anything I might ask for is not going
to happen -- and of course what I was pointing out, _not_ asking for, was
that you can't expect to get new developers on board if they aren't going to
be allowed to scratch their itches.
> 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.
You've just had some. The response was "you're wrong".
Andy
--
Dr Andy Parkins
andyparkins at gmail.com