📅 Original date posted:2015-06-25
📝 Original message:These are the kind of silly responses you often get when this subject
comes up. Mr. Garzik knows how to ignore messages he doesn't want so I
see no need for him to use the list to attack people he doesn't agree
with and/or try to interfere with discussions of others on the list.
He turns it into a personality discussion rather than a discussion of
Systems Engineering. He also tries to intimate anyone who brings up the
discussion and "punish" them as a lesson to anyone else who may raise
the issue.
It is interesting that people like that are attracted to a decentralized
system. The reply is simply an attempt at protecting turf which is why
Mr. Garzik's vague replies are never taken seriously on the subject of
decision-making process for the software.
Russ
On 6/25/2015 1:07 AM, Jeff Garzik wrote:
> Ladies & gents, please do not feed the troll. This has been explained
> to Milly multiple times in the past, on previous mailing list & github
> with no impact.
>
>
> On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin <milly at bitcoins.info
> <mailto:milly at bitcoins.info>> wrote:
>
> I'm sorry but that is the kind of defensive, cultish response
> everyone gets when they ask that question. If you had a well
> constructed documented process then you would be able to point to
> it ... but you can't. While there are a few bits and pieces
> scattered about in different places there is no coherent plan or
> process.
>
> It is easy to make statements like "consensus must be unanimous"
> but the issue is that you never have true 100% consensus yet you
> have to move forward in some fashion and everyone has to run
> software with the same consensus rules. The issue is how you move
> forward is the question that nobody wants to answer because (a) it
> is a hard question to answer and (b) developers see it as a threat
> to their authority/position. If people just keep shutting down
> the discussion with a bunch of cultish stock answers then you are
> never going to move forward with developing some kind of process.
>
> From what I can see much of the discussion is personality-driven
> and not based on Computer Science or and defined process. The
> issue is that a personality has changed so the process is
> perceived to be different and some people want to hard fork.
> Previously, the cultish answer is that Bitcoin development is
> decentralized because people can fork the code. Now that some
> developers want to fork the code suddenly it is a big problem.
> Is forking the code part of the consensus process or is it the
> work of the devil? The fact that there is so much diverse
> opinion on this shows a defined process has never been fully
> vetted or understood.
>
> I have worked on these processes for many years for projects
> orders of magnitudes larger than Bitcoin. I can absolutely assure
> you the current mishmash does not scale and huge amounts of time
> are wasted. That should be readily apparent from the recent
> discussions and the recent concern it has caused from people
> outside the developer's inner circle.
>
> Lack of defined process = high risk and wasted effort.
>
> Russ
>
>
>
>
>
> On 6/24/2015 9:50 PM, Mark Friedenbach wrote:
>> I'm sorry but this is absolutely not the case, Milly. The reason
>> that people get defensive is that we have a carefully constructed
>> process that does work (thank you very much!) and is well
>> documented. We talk about it quite often in fact as it is a
>> defining characteristic of how bitcoin is developed which differs
>> in some ways from how other open source software is developed --
>> although it remains the same in most other ways.
>>
>> Changes to the non-consensus sections of Bitcoin Core tend to get
>> merged when there are a few reviews, tests, and ACKs from
>> recognized developers, there are no outstanding objections, and
>> the maintainer doing the merge makes a subjective judgement that
>> the code is ready.
>>
>> Consensus-changes, on the other hand, get merged into Bitcoin
>> Core only after the above criteria are met AND an extremely long
>> discussion period that has given all the relevant stakeholders a
>> chance to comment, and no significant objections remain.
>> Consensus-code changes are unanimous. They must be.
>>
>> The sort of process that exists in standards bodies for example,
>> with working groups and formal voting procedures, has no place
>> where changes define the nature and validity of other people's
>> money. Who has the right to reach into your pocket and define how
>> you can or cannot spend your coins? The premise of bitcoin is
>> that no one has that right, yet that is very much what we do when
>> consensus code changes are made. That is why when we make a
>> change to the rules governing the nature of bitcoin, we must make
>> sure that everyone is made aware of the change and consents to it.
>>
>> Everyone. Does this work? Does this scale? So far, it does.
>> Uncontroversial changes, such as BIP 66, are deployed without
>> issue. Every indication is that BIP 66 will complete deployment
>> in the very near future, and we intend to repeat this process for
>> more interesting changes such as BIP65: CHECKLOCKTIMEVERIFY.
>>
>> This isn't about no one stepping forward to be the "decider."
>> This is about no one having the right to decide these things on
>> the behalf of others. If a contentious change is proposed and not
>> accepted by the process of consensus, that is because the process
>> is doing its job at rejecting controversial changes. It has
>> nothing to do with personality, and everything to do with the
>> nature of bitcoin itself.
>>
>>
>> On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin
>> <milly at bitcoins.info <mailto:milly at bitcoins.info>> wrote:
>>
>> I have seen this question asked many times. Most developers
>> become defensive and they usually give a very vague
>> 1-sentence answer when this question is asked. It seems to
>> be it is based on personalities rather than any kind of
>> definable process. To have that discussion the personalities
>> must be separated out and answers like "such-and-such
>> wouldn't do that" don't really do much to advance the
>> discussion. Also, the incentive for new developers to come in
>> is that they will be paid by companies who want to influence
>> the code and this should be considered (some developers take
>> this statement as an insult when it is just a statement of
>> the incentive process).
>>
>> The other problem you are having is the lead developer does
>> not want to be a "decider" when, in fact, he is a very
>> significant decider. While the users have the ultimate
>> choice in a practical sense the chief developer is the
>> "decider." Now people don't want to get him upset so nobody
>> wants to push the issue or fully define the process. Now you
>> are left with a broken, unwritten/unspoken process. While
>> this type of thing may work with a small group of developers
>> businesses/investors looking in from the outside will see
>> this as a risk.
>>
>> Until you get passed all the personality-based arguments you
>> are going to have a tough time defining a real process.
>>
>> Russ
>>
>>
>>
>>
>>
>>
>> On 6/24/2015 7:41 PM, Raystonn wrote:
>>
>> I would like to start a civil discussion on an undefined,
>> or at least unwritten, portion of the BIP process. Who
>> should get to vote on approval to commit a BIP
>> implementation into Bitcoin Core? Is a simple majority
>> of these voters sufficient for approval? If not, then
>> what is?
>>
>> Raystonn
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/3deb2320/attachment.html>;
Milly Bitcoin [ARCHIVE] /
npub1rv…hc5wt
2023-06-07 15:40:06
in reply to nevent1q…tjgn
Author Public Key
npub1rv5ajnhgrc0wq3ulrk6tcjkgsaq8h4rs5rtsvrnklz4j0lw40egqphc5wtPublished at
2023-06-07 15:40:06Event JSON
{
"id": "016f7a25e1c658b6e30e886ba7af7fefb9db6820da0f0fe256ecbcc1c48baffe",
"pubkey": "1b29d94ee81e1ee0479f1db4bc4ac887407bd470a0d7060e76f8ab27fdd57e50",
"created_at": 1686152406,
"kind": 1,
"tags": [
[
"e",
"3fe09b8bc3b13f27e42579b8ab63a325ab25d17e0571ce6b5f141d69b2abe4bf",
"",
"root"
],
[
"e",
"1d36d443ea0ce7d023a408029a9d367c26d093ffac35ab232bdee86ff6486639",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2015-06-25\n📝 Original message:These are the kind of silly responses you often get when this subject \ncomes up. Mr. Garzik knows how to ignore messages he doesn't want so I \nsee no need for him to use the list to attack people he doesn't agree \nwith and/or try to interfere with discussions of others on the list.\nHe turns it into a personality discussion rather than a discussion of \nSystems Engineering. He also tries to intimate anyone who brings up the \ndiscussion and \"punish\" them as a lesson to anyone else who may raise \nthe issue.\n\nIt is interesting that people like that are attracted to a decentralized \nsystem. The reply is simply an attempt at protecting turf which is why \nMr. Garzik's vague replies are never taken seriously on the subject of \ndecision-making process for the software.\n\nRuss\n\n\nOn 6/25/2015 1:07 AM, Jeff Garzik wrote:\n\u003e Ladies \u0026 gents, please do not feed the troll. This has been explained \n\u003e to Milly multiple times in the past, on previous mailing list \u0026 github \n\u003e with no impact.\n\u003e\n\u003e\n\u003e On Wed, Jun 24, 2015 at 7:34 PM, Milly Bitcoin \u003cmilly at bitcoins.info \n\u003e \u003cmailto:milly at bitcoins.info\u003e\u003e wrote:\n\u003e\n\u003e I'm sorry but that is the kind of defensive, cultish response\n\u003e everyone gets when they ask that question. If you had a well\n\u003e constructed documented process then you would be able to point to\n\u003e it ... but you can't. While there are a few bits and pieces\n\u003e scattered about in different places there is no coherent plan or\n\u003e process.\n\u003e\n\u003e It is easy to make statements like \"consensus must be unanimous\"\n\u003e but the issue is that you never have true 100% consensus yet you\n\u003e have to move forward in some fashion and everyone has to run\n\u003e software with the same consensus rules. The issue is how you move\n\u003e forward is the question that nobody wants to answer because (a) it\n\u003e is a hard question to answer and (b) developers see it as a threat\n\u003e to their authority/position. If people just keep shutting down\n\u003e the discussion with a bunch of cultish stock answers then you are\n\u003e never going to move forward with developing some kind of process.\n\u003e\n\u003e From what I can see much of the discussion is personality-driven\n\u003e and not based on Computer Science or and defined process. The\n\u003e issue is that a personality has changed so the process is\n\u003e perceived to be different and some people want to hard fork. \n\u003e Previously, the cultish answer is that Bitcoin development is\n\u003e decentralized because people can fork the code. Now that some\n\u003e developers want to fork the code suddenly it is a big problem. \n\u003e Is forking the code part of the consensus process or is it the\n\u003e work of the devil? The fact that there is so much diverse\n\u003e opinion on this shows a defined process has never been fully\n\u003e vetted or understood.\n\u003e\n\u003e I have worked on these processes for many years for projects\n\u003e orders of magnitudes larger than Bitcoin. I can absolutely assure\n\u003e you the current mishmash does not scale and huge amounts of time\n\u003e are wasted. That should be readily apparent from the recent\n\u003e discussions and the recent concern it has caused from people\n\u003e outside the developer's inner circle.\n\u003e\n\u003e Lack of defined process = high risk and wasted effort.\n\u003e\n\u003e Russ\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On 6/24/2015 9:50 PM, Mark Friedenbach wrote:\n\u003e\u003e I'm sorry but this is absolutely not the case, Milly. The reason\n\u003e\u003e that people get defensive is that we have a carefully constructed\n\u003e\u003e process that does work (thank you very much!) and is well\n\u003e\u003e documented. We talk about it quite often in fact as it is a\n\u003e\u003e defining characteristic of how bitcoin is developed which differs\n\u003e\u003e in some ways from how other open source software is developed --\n\u003e\u003e although it remains the same in most other ways.\n\u003e\u003e\n\u003e\u003e Changes to the non-consensus sections of Bitcoin Core tend to get\n\u003e\u003e merged when there are a few reviews, tests, and ACKs from\n\u003e\u003e recognized developers, there are no outstanding objections, and\n\u003e\u003e the maintainer doing the merge makes a subjective judgement that\n\u003e\u003e the code is ready.\n\u003e\u003e\n\u003e\u003e Consensus-changes, on the other hand, get merged into Bitcoin\n\u003e\u003e Core only after the above criteria are met AND an extremely long\n\u003e\u003e discussion period that has given all the relevant stakeholders a\n\u003e\u003e chance to comment, and no significant objections remain.\n\u003e\u003e Consensus-code changes are unanimous. They must be.\n\u003e\u003e\n\u003e\u003e The sort of process that exists in standards bodies for example,\n\u003e\u003e with working groups and formal voting procedures, has no place\n\u003e\u003e where changes define the nature and validity of other people's\n\u003e\u003e money. Who has the right to reach into your pocket and define how\n\u003e\u003e you can or cannot spend your coins? The premise of bitcoin is\n\u003e\u003e that no one has that right, yet that is very much what we do when\n\u003e\u003e consensus code changes are made. That is why when we make a\n\u003e\u003e change to the rules governing the nature of bitcoin, we must make\n\u003e\u003e sure that everyone is made aware of the change and consents to it.\n\u003e\u003e\n\u003e\u003e Everyone. Does this work? Does this scale? So far, it does.\n\u003e\u003e Uncontroversial changes, such as BIP 66, are deployed without\n\u003e\u003e issue. Every indication is that BIP 66 will complete deployment\n\u003e\u003e in the very near future, and we intend to repeat this process for\n\u003e\u003e more interesting changes such as BIP65: CHECKLOCKTIMEVERIFY.\n\u003e\u003e\n\u003e\u003e This isn't about no one stepping forward to be the \"decider.\"\n\u003e\u003e This is about no one having the right to decide these things on\n\u003e\u003e the behalf of others. If a contentious change is proposed and not\n\u003e\u003e accepted by the process of consensus, that is because the process\n\u003e\u003e is doing its job at rejecting controversial changes. It has\n\u003e\u003e nothing to do with personality, and everything to do with the\n\u003e\u003e nature of bitcoin itself.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Wed, Jun 24, 2015 at 5:07 PM, Milly Bitcoin\n\u003e\u003e \u003cmilly at bitcoins.info \u003cmailto:milly at bitcoins.info\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e I have seen this question asked many times. Most developers\n\u003e\u003e become defensive and they usually give a very vague\n\u003e\u003e 1-sentence answer when this question is asked. It seems to\n\u003e\u003e be it is based on personalities rather than any kind of\n\u003e\u003e definable process. To have that discussion the personalities\n\u003e\u003e must be separated out and answers like \"such-and-such\n\u003e\u003e wouldn't do that\" don't really do much to advance the\n\u003e\u003e discussion. Also, the incentive for new developers to come in\n\u003e\u003e is that they will be paid by companies who want to influence\n\u003e\u003e the code and this should be considered (some developers take\n\u003e\u003e this statement as an insult when it is just a statement of\n\u003e\u003e the incentive process).\n\u003e\u003e\n\u003e\u003e The other problem you are having is the lead developer does\n\u003e\u003e not want to be a \"decider\" when, in fact, he is a very\n\u003e\u003e significant decider. While the users have the ultimate\n\u003e\u003e choice in a practical sense the chief developer is the\n\u003e\u003e \"decider.\" Now people don't want to get him upset so nobody\n\u003e\u003e wants to push the issue or fully define the process. Now you\n\u003e\u003e are left with a broken, unwritten/unspoken process. While\n\u003e\u003e this type of thing may work with a small group of developers\n\u003e\u003e businesses/investors looking in from the outside will see\n\u003e\u003e this as a risk.\n\u003e\u003e\n\u003e\u003e Until you get passed all the personality-based arguments you\n\u003e\u003e are going to have a tough time defining a real process.\n\u003e\u003e\n\u003e\u003e Russ\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On 6/24/2015 7:41 PM, Raystonn wrote:\n\u003e\u003e\n\u003e\u003e I would like to start a civil discussion on an undefined,\n\u003e\u003e or at least unwritten, portion of the BIP process. Who\n\u003e\u003e should get to vote on approval to commit a BIP\n\u003e\u003e implementation into Bitcoin Core? Is a simple majority\n\u003e\u003e of these voters sufficient for approval? If not, then\n\u003e\u003e what is?\n\u003e\u003e\n\u003e\u003e Raystonn\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150625/3deb2320/attachment.html\u003e",
"sig": "e9e6a100247d398307ff80d1a9f3e1c46fe181fe88d1c500c8be3805889042de7ce384e9a58a580f8aa5a6e13d4b0d37efaa90c2133aa3e5ec46348a26dbda9a"
}