📅 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
Andy Parkins [ARCHIVE] /
npub1nx…7wjrv
2023-06-07 02:14:26
in reply to nevent1q…tw5v
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvPublished at
2023-06-07 02:14:26Event JSON
{
"id": "e73634957ada40e22969ed7c608f7ff4ad5c5fd03b38c477e7b376b2be9e0186",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686104066,
"kind": 1,
"tags": [
[
"e",
"fe8ae56772ad6135ef8f3cc5e223de1011f21616a51d5302085d2b9ebf339345",
"",
"root"
],
[
"e",
"4bd5b61c1c3270427ab2a5a84bba1921873207b39981cf4a861c37cc6d69bbb4",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2011-08-11\n🗒️ Summary of this message: A developer suggests delaying incompatible changes until they have propagated, but the community is hard-wired against breaking changes.\n📝 Original message:On Thursday 11 August 2011 04:20:25 Jeff Garzik wrote:\n\n\u003e \u003e However... The version number field combined with the massive\n\u003e \u003e complexity of:\n\u003e \u003e \n\u003e \u003e if( blockNumber \u003e 500000 )\n\u003e \u003e new_process();\n\u003e \u003e else\n\u003e \u003e old_process();\n\u003e \u003e \n\u003e \u003e Would sort all of your \"compatibility\" objections out, and would give\n\u003e \u003e nodes time to upgrade.\n\u003e \n\u003e The above has been discussed on the forums. The community seems to\n\u003e consider that option one of last resort, because the consequences of\n\u003e -not- upgrading immediately become \"I cannot access my money.\" The\n\nDid you even read what I wrote? \"if( blockNumber \u003e 5000000 )\" is about as \nfar from immediate as you can get. I'm not an idiot; I understand we can't \nlock people out of their money simply because of a software upgrade. It's \nnot unreasonable to expect people will have upgraded by block 500000 though \n(or whatever number the community decided upon).\n\nAgain you're missing my point... you are still shooting ideas down.\n\n\u003e community also seems rather hard-wired against breaking changes like\n\u003e that, because it implies that we lowly dev peons are daring to mess\n\u003e with the Blessed Satoshi Design that has received extensive study, and\n\u003e 100% communal agreement.\n\nWell the community had better unhardwire itself or its going to end up with \nfive developers and no more.\n\n\u003e If the community changes its mind, and there are strong calls to make\n\u003e a breaking change, we can certainly do that. Bitcoin is not only open\n\u003e source but very much democratic -- people vote by choosing which\n\u003e client software to use.\n\nVoting with ones feet should be a last resort. Wouldn't it be better not to \nend up with incompatible clients out there?\n\n\u003e Historically speaking, the protocol has had minor tweaks, if you check\n\u003e the patch history. Adding new protocol commands is pretty easy, for\n\u003e example. Removing commands tends to be high cost for low benefit\n\u003e (\"protocol removes a harmless redundancy\"), if you're messing with the\n\u003e initial negotiation sequence. IMO verack is not redundant, anyway.\n\nClient: I speak version 10\nServer: hmmm, I don't speak version 10, I only speak version 5\nClient: I am willing to lower to version 5 so I shall continue\n\nor\n\nClient: I speak version 10\nServer: hmmm, I don't speak version 10, I only speak version 5\nClient: I am unwilling to lower to version 5 so I shall hang up\n\nor\n\nClient: I speak version 5\nServer: hmmm, I speak version 10, but I am willing to speak version 5\n\nor\n\nClient: I speak version 5\nServer: hmmm, I speak version 10, and I am unwilling to speak version 5\n so I shall hang up\n\n'verack' is redundant. It sends no information and merely says that the \nother end is willing to continue. Willing to continue is easily determined \nwhen the remote continues. Handling 'verack' is an annoyance, and adds \nnothing.\n\n\u003e But the answer is \"what do the users want\" not \"no\" At the end of the\n\u003e day we're here to adequately reflect the needs of our userbase at all.\n\u003e And so far, the userbase seems highly conservative when it comes to\n\u003e incompatible changes. Correct me if I'm wrong...\n\nPlease point me at a single incompatible change that has been rejected by \nthe userbase.\n\nFurther: I'm not suggesting incompatible changes alone; that would be \ninsane. I'm suggesting upgrade paths that delay incompatible changes until \nthe change has propagated.\n\n\u003e It's negative to weight costs vs. benefits? That is what I expect any\n\u003e good engineer to do.\n\nI don't think that's what's happening. Not once have I seen the \"benefits\" \nside of that equation. What I have seen is plenty of \"I can't see a use \ncase for that\"; when the key word in that sentence is \"I\".\n\n\u003e In any case, our -users- are not clamoring for breaking changes of the\n\u003e type you describe above, as far as I can see. Just the opposite. So\n\u003e if you want to deploy a breaking change, the burden is on you to\n\u003e convince the bitcoin users and miners that it's a good idea.\n\nThe users aren't typically going to be familiar enough with the internals of \nbitcoin to care about many of the changes I suggested. I have repeatedly \nsaid I don't want to break anything, I want to transition in an orderly \nfashion (and the majority of my suggestions were backward compatible). But \nof course, I don't actually want to do anything with bitcoind itself, it's \nbeen made repeatedly clear to me that anything I might ask for is not going \nto happen -- and of course what I was pointing out, _not_ asking for, was \nthat you can't expect to get new developers on board if they aren't going to \nbe allowed to scratch their itches.\n\n\u003e If the bitcoin dev team is not accurately reflecting the desire of its\n\u003e users, then that should be corrected, and we want to hear feedback.\n\nYou've just had some. The response was \"you're wrong\".\n\n\n\nAndy\n-- \nDr Andy Parkins\nandyparkins at gmail.com",
"sig": "534fbad49542fb5cc17b8b0f59d76fd7a01dee81b966a1161b6d9cd9da41692f867831d25aea5f7a0d98df150f53506b6c714be5955dc54e4ca2f7954d4f6468"
}