Ricardo Filipe [ARCHIVE] on Nostr: đź“… Original date posted:2015-06-28 đź“ť Original message:Then demonstrate it. He ...
đź“… Original date posted:2015-06-28
đź“ť Original message:Then demonstrate it. He has been raising quite valid points over the
maintenance of bitcoin core.
This is the same problem as the changes to consensus rules in bitcoin
core: they aren't explicitly defined for the external audience. Thus
forcing people to lobby for hard forks.
2015-06-28 21:16 GMT+01:00 Mark Friedenbach <mark at friedenbach.org>:
> Milly you are absolutely wrong as has been pointed out by numerous people
> numerous times. Your idea of how bitcoin development decision making works
> is demonstrably false. Please stop filling our inboxes with trolling
> accusations, or else this will have to become a moderated list. And no one
> wants that.
>
> On Jun 28, 2015 1:11 PM, "Milly Bitcoin" <milly at bitcoins.info> wrote:
>>
>> I really don't know who has power to do what behind the scenes. From what
>> i understand, if push comes to shove, it is under the ultimate control of
>> one person who can revoke commit privileges. Maybe I am wrong about that
>> but the point is most people don't know for sure.
>>
>> You are correct about the people having the choice to download but the
>> influence of the official release is way beyond the influence of any forked
>> release. What that means in the real world is an open question and would be
>> different depending upon the specific circumstances and difficult to
>> predict. It is significant power to have control over the official release
>> at the present time. If they did not have significant power people would
>> not spend significant efforts lobbying them to make changes. Any new
>> developers hired by companies will do so because they can influence over the
>> official release since that is the only incentive.
>>
>> It seems to me that this block size fork is only the beginning of the
>> issues that will arise over the coming years. Whatever powers the core
>> maintainers have it is going to be exploited one way or another as time goes
>> on. Maybe there are enough feedback mechanisms to protect against that, I
>> don't really know.
>>
>> Russ
>>
>>
>>
>>
>>
>> On 6/28/2015 3:05 PM, Patrick Murck wrote:
>>
>> Wladimir has no more or less “power” to push change to the Bitcoin Core
>> codebase than any other person with commit privileges to the GitHub repo. If
>> I’m not mistaken there are 7 people with commit privileges and five of them
>> are active. If Wladimir committed a change it could be reverted by any of
>> the others. This is by design and ensures that changes will have reached
>> some level of technical consensus before they are merged, among other
>> things.
>>
>> Furthermore even assuming the Core Maintainer commits a change to Bitcoin
>> Core (that isn’t reverted and that gets packaged up into the next code
>> release) that still doesn’t push a change to the bitcoin network. There is
>> no auto-update on Bitcoin Core so individuals and companies running Bitcoin
>> Core software have to choose to upgrade. Further still, developers that
>> maintain alternative implementations would have to decide to merge those
>> changes to the codebase they are indepently maintaining (and their users
>> would need to update, etc.).
>>
>> I understand why it might *seem* to be the case that the Core Maintainer
>> is empowered to make changes to "teh Bitcoin" but the reality is that the
>> Core Maintainer role is really about cat herding and project management of
>> Bitcoin Core the open-source software project and not the bitcoin network.
>> We’re lucky Wladimir has agreed to take on so much of the scut work to keep
>> the project moving forward.
>>
>> The process might get ugly and inefficient but that’s the cost of having
>> no wizard behind the curtain.
>>
>> -pm
>>
>> --
>> Patrick Murck
>>
>> On June 28, 2015 at 9:23:47 AM, Milly Bitcoin (milly at bitcoins.info) wrote:
>>
>> The core maintainer has always been in control of the consensus rules.
>> Satoshi came up with the rules and put them in there. Since then any
>> changes to any part of the code go through the core maintainer. It
>> looks to me as if people are saying it somehow changed along the way
>> because they don't want to hurt people's feeling, upset up, get them to
>> quit, etc. Sure there are checks and balances and people don't have to
>> use the main code base but if they change the consensus rules they are
>> incompatible.
>>
>> The notion that because people can download different rules and run them
>> is interesting from a theoretical perspective but that is constrained by
>> the network effect. I can say the US government is not the "decider" of
>> laws because I can vote them out, recall them, challenge things in
>> court, or secede and start my own country. You can also say the
>> judge/jury in a criminal court case is not a "decider" because the
>> president can always issue a pardon. But those points are generally not
>> useful in a practical sense.
>>
>> The issue about the developers is the tremendous influence they have to
>> veto any changes. I don't have veto power yet I have more bitcoins than
>> garzik says he has. The whole Bitcoin software development system is
>> subject to attack from just a couple of people who have this veto
>> power. With all the crying and moaning about centralization on this
>> list I would think that would be a concern.
>>
>> Russ
>>
>>
>>
>> On 6/28/2015 11:35 AM, Jorge TimĂłn wrote:
>> > On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <milly at bitcoins.info>
>> > wrote:
>> >> I never said something was approved by garzik added something after it
>> >> was
>> >> opposed. What I said was a proposal was made and 4 people commented on
>> >> the
>> >> Github. He then tweeted there was near universal approval before most
>> >> people even heard about the subject. It was not controversial but i was
>> >> pointing out the arrogance of some of the developers. He considers the
>> >> entire universe of Bitcoin stakeholders to be a very small group of
>> >> insiders, not the entire universe of Bitcoin users. Another thing I
>> >> have
>> >> seen on Github for bitcoin.org is how some the maintainers change the
>> >> rules
>> >> on the fly. Sometimes they say a proposal had no objections so it is
>> >> approved. Other times they say a proposal has no support so it is
>> >> rejected.
>> > Ok, I misunderstood.
>> > Well, the fact is that the number of capable reviewers is quite small.
>> > If more companies hired and trained more developers to become bitcoin
>> > core developers that situation could change, but that's where we are
>> > now.
>> >
>> >> You are also trying to say that the core developers actually have
>> >> little
>> >> influence and are not "deciders" because anyone can fork the code. That
>> >> has
>> >> already been discussed at length and such an argument is faulty because
>> >> there is a constraint that your software is incompatible with everyone
>> >> else.
>> > Only if you change the consensus rules (which are, in fact, a
>> > relatively small part of the code).
>> > Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches
>> > with the replace by fee policy, libbitcoin also changes many
>> > non-consensus things, there's code written in other languages...
>> > There's multiple counter-examples to your claim of that argument being
>> > faulty.
>> > Seriously, forking the project is just one click. You should try it
>> > out like at least 9627 other people have done.
>> > >From there, you can pay your own developers (if you don't know how to
>> > code yourself) and maybe they're also fine being insulted by you as
>> > part of the job.
>> > What you still can't do is unilaterally change the consensus rules of
>> > a running p2p consensus system, because you cannot force the current
>> > users to run any software they don't want to run.
>> >
>> >> The issue is that there is no way right now to change the consensus
>> >> rules
>> >> except to go through the core maintainer unless you get everybody on
>> >> the
>> >> network to switch to your fork. People who keep repeating that the
>> >> software
>> >> development is "decentralized because you fork the code" without
>> >> explaining
>> >> the constraints are just cultists.
>> > Please, stop the cultist crap. Maybe insulting people like that is how
>> > you got people to call you a troll.
>> > But, yes, you are right: there's no known mechanism for safely
>> > deploying controversial changes to the consensus rules
>> >
>> >> The discussion has nothing to do with who has the position now and I
>> >> never
>> >> said he has "control over the consensus rules." The maintainer has a
>> >> very
>> >> large influence way beyond anyone else. As for your claim that I want
>> >> someone hurt because I am explaining the process, that is ridiculous.
>> >> If
>> >> the Core maintainers did not have significant influence to change the
>> >> consensus rules then everybody would not be spending all this time
>> >> lobbying
>> >> them to have them changed.
>> > Well, if you don't think he has control over the consensus rules we're
>> > advancing.
>> > I think that was implied from some of your previous claims. He is no
>> > "decider" on consensus changes.
>> > Insisting on it can indeed get him hurt, so I'm happy that you're
>> > taking that back (or clarifying that really wasn't your position).
>> > Influence is very relative and not only core devs have "influence".
>> > Maybe Andreas Antonopolous has more "influence" than I have because he
>> > is a more public figure?
>> > Well, that's fine I think. I don't see the point in discussing who has
>> > how much influence.
>> >
>> >> The outside influences and stake of the developer is a relevant topic.
>> >> The
>> >> same types of things are discussed on this list all the time in the
>> >> context
>> >> of miners, users, merchants, and exchanges. Again, the developers try
>> >> to
>> >> place themselves on some kind of pedestal where they are the protectors
>> >> and
>> >> pure and everyone else (miners, users, merchants) are abusers,
>> >> spammers,
>> >> attackers, scammers, cheaters, etc. It is Garzik who voluntarily made
>> >> an
>> >> issue of how many bitcoins he holds and he made that issue in the same
>> >> place
>> >> where he announces many of the technical issues. It is very relevant
>> >> that
>> >> he has a minimal stake in Bitcoin holdings yet he goes around making
>> >> major
>> >> decisions about Bitcoin and trying to dictate who is allowed to
>> >> participate
>> >> in discussions. If a core developer has minimal stake in Bitcoin yet
>> >> has
>> >> major veto power over code change that is a problem.
>> > Please, don't generalize. I don't think I put myself in any kind of
>> > pedestal.
>> > That is insulting to me and many others (you may not even know and
>> > you're insulting them).
>> > And I think my Bitcoin holdings are completely irrelevant when judging
>> > my contributions to the software: either they're good or not, and who
>> > I am or how many Bitcoins I have at any given time shouldn't matter.
>> > Again, nobody forces you to use our software, as said there's
>> > alternatives (including forking the project right now).
>> >
>> >> You are correct that you cannot give power to any person over the
>> >> Internet
>> >> which is why some kind of process needs to be developed that does not
>> >> involve trying to convince one person to make the changes or a system
>> >> that
>> >> depends on unwritten, ever-changing rules maintained by a handful of
>> >> people.
>> > Well, for now the process we have is seeking consensus, and although
>> > our definition of "uncontroversial" is very vague, I think it is quite
>> > obvious when a proposed change is not "uncontroversial" (like in the
>> > block size debate).
>> > It seems to me that any other "formal process" would imply
>> > centralization in the decision making of the consensus rules (and from
>> > there you only have to corrupt that centralized organization to
>> > destroy Bitcoin).
>> >
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> 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
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
đź“ť Original message:Then demonstrate it. He has been raising quite valid points over the
maintenance of bitcoin core.
This is the same problem as the changes to consensus rules in bitcoin
core: they aren't explicitly defined for the external audience. Thus
forcing people to lobby for hard forks.
2015-06-28 21:16 GMT+01:00 Mark Friedenbach <mark at friedenbach.org>:
> Milly you are absolutely wrong as has been pointed out by numerous people
> numerous times. Your idea of how bitcoin development decision making works
> is demonstrably false. Please stop filling our inboxes with trolling
> accusations, or else this will have to become a moderated list. And no one
> wants that.
>
> On Jun 28, 2015 1:11 PM, "Milly Bitcoin" <milly at bitcoins.info> wrote:
>>
>> I really don't know who has power to do what behind the scenes. From what
>> i understand, if push comes to shove, it is under the ultimate control of
>> one person who can revoke commit privileges. Maybe I am wrong about that
>> but the point is most people don't know for sure.
>>
>> You are correct about the people having the choice to download but the
>> influence of the official release is way beyond the influence of any forked
>> release. What that means in the real world is an open question and would be
>> different depending upon the specific circumstances and difficult to
>> predict. It is significant power to have control over the official release
>> at the present time. If they did not have significant power people would
>> not spend significant efforts lobbying them to make changes. Any new
>> developers hired by companies will do so because they can influence over the
>> official release since that is the only incentive.
>>
>> It seems to me that this block size fork is only the beginning of the
>> issues that will arise over the coming years. Whatever powers the core
>> maintainers have it is going to be exploited one way or another as time goes
>> on. Maybe there are enough feedback mechanisms to protect against that, I
>> don't really know.
>>
>> Russ
>>
>>
>>
>>
>>
>> On 6/28/2015 3:05 PM, Patrick Murck wrote:
>>
>> Wladimir has no more or less “power” to push change to the Bitcoin Core
>> codebase than any other person with commit privileges to the GitHub repo. If
>> I’m not mistaken there are 7 people with commit privileges and five of them
>> are active. If Wladimir committed a change it could be reverted by any of
>> the others. This is by design and ensures that changes will have reached
>> some level of technical consensus before they are merged, among other
>> things.
>>
>> Furthermore even assuming the Core Maintainer commits a change to Bitcoin
>> Core (that isn’t reverted and that gets packaged up into the next code
>> release) that still doesn’t push a change to the bitcoin network. There is
>> no auto-update on Bitcoin Core so individuals and companies running Bitcoin
>> Core software have to choose to upgrade. Further still, developers that
>> maintain alternative implementations would have to decide to merge those
>> changes to the codebase they are indepently maintaining (and their users
>> would need to update, etc.).
>>
>> I understand why it might *seem* to be the case that the Core Maintainer
>> is empowered to make changes to "teh Bitcoin" but the reality is that the
>> Core Maintainer role is really about cat herding and project management of
>> Bitcoin Core the open-source software project and not the bitcoin network.
>> We’re lucky Wladimir has agreed to take on so much of the scut work to keep
>> the project moving forward.
>>
>> The process might get ugly and inefficient but that’s the cost of having
>> no wizard behind the curtain.
>>
>> -pm
>>
>> --
>> Patrick Murck
>>
>> On June 28, 2015 at 9:23:47 AM, Milly Bitcoin (milly at bitcoins.info) wrote:
>>
>> The core maintainer has always been in control of the consensus rules.
>> Satoshi came up with the rules and put them in there. Since then any
>> changes to any part of the code go through the core maintainer. It
>> looks to me as if people are saying it somehow changed along the way
>> because they don't want to hurt people's feeling, upset up, get them to
>> quit, etc. Sure there are checks and balances and people don't have to
>> use the main code base but if they change the consensus rules they are
>> incompatible.
>>
>> The notion that because people can download different rules and run them
>> is interesting from a theoretical perspective but that is constrained by
>> the network effect. I can say the US government is not the "decider" of
>> laws because I can vote them out, recall them, challenge things in
>> court, or secede and start my own country. You can also say the
>> judge/jury in a criminal court case is not a "decider" because the
>> president can always issue a pardon. But those points are generally not
>> useful in a practical sense.
>>
>> The issue about the developers is the tremendous influence they have to
>> veto any changes. I don't have veto power yet I have more bitcoins than
>> garzik says he has. The whole Bitcoin software development system is
>> subject to attack from just a couple of people who have this veto
>> power. With all the crying and moaning about centralization on this
>> list I would think that would be a concern.
>>
>> Russ
>>
>>
>>
>> On 6/28/2015 11:35 AM, Jorge TimĂłn wrote:
>> > On Sun, Jun 28, 2015 at 3:13 PM, Milly Bitcoin <milly at bitcoins.info>
>> > wrote:
>> >> I never said something was approved by garzik added something after it
>> >> was
>> >> opposed. What I said was a proposal was made and 4 people commented on
>> >> the
>> >> Github. He then tweeted there was near universal approval before most
>> >> people even heard about the subject. It was not controversial but i was
>> >> pointing out the arrogance of some of the developers. He considers the
>> >> entire universe of Bitcoin stakeholders to be a very small group of
>> >> insiders, not the entire universe of Bitcoin users. Another thing I
>> >> have
>> >> seen on Github for bitcoin.org is how some the maintainers change the
>> >> rules
>> >> on the fly. Sometimes they say a proposal had no objections so it is
>> >> approved. Other times they say a proposal has no support so it is
>> >> rejected.
>> > Ok, I misunderstood.
>> > Well, the fact is that the number of capable reviewers is quite small.
>> > If more companies hired and trained more developers to become bitcoin
>> > core developers that situation could change, but that's where we are
>> > now.
>> >
>> >> You are also trying to say that the core developers actually have
>> >> little
>> >> influence and are not "deciders" because anyone can fork the code. That
>> >> has
>> >> already been discussed at length and such an argument is faulty because
>> >> there is a constraint that your software is incompatible with everyone
>> >> else.
>> > Only if you change the consensus rules (which are, in fact, a
>> > relatively small part of the code).
>> > Mike mantains Bitcoin XT and that's fine, Peter Todd maintains patches
>> > with the replace by fee policy, libbitcoin also changes many
>> > non-consensus things, there's code written in other languages...
>> > There's multiple counter-examples to your claim of that argument being
>> > faulty.
>> > Seriously, forking the project is just one click. You should try it
>> > out like at least 9627 other people have done.
>> > >From there, you can pay your own developers (if you don't know how to
>> > code yourself) and maybe they're also fine being insulted by you as
>> > part of the job.
>> > What you still can't do is unilaterally change the consensus rules of
>> > a running p2p consensus system, because you cannot force the current
>> > users to run any software they don't want to run.
>> >
>> >> The issue is that there is no way right now to change the consensus
>> >> rules
>> >> except to go through the core maintainer unless you get everybody on
>> >> the
>> >> network to switch to your fork. People who keep repeating that the
>> >> software
>> >> development is "decentralized because you fork the code" without
>> >> explaining
>> >> the constraints are just cultists.
>> > Please, stop the cultist crap. Maybe insulting people like that is how
>> > you got people to call you a troll.
>> > But, yes, you are right: there's no known mechanism for safely
>> > deploying controversial changes to the consensus rules
>> >
>> >> The discussion has nothing to do with who has the position now and I
>> >> never
>> >> said he has "control over the consensus rules." The maintainer has a
>> >> very
>> >> large influence way beyond anyone else. As for your claim that I want
>> >> someone hurt because I am explaining the process, that is ridiculous.
>> >> If
>> >> the Core maintainers did not have significant influence to change the
>> >> consensus rules then everybody would not be spending all this time
>> >> lobbying
>> >> them to have them changed.
>> > Well, if you don't think he has control over the consensus rules we're
>> > advancing.
>> > I think that was implied from some of your previous claims. He is no
>> > "decider" on consensus changes.
>> > Insisting on it can indeed get him hurt, so I'm happy that you're
>> > taking that back (or clarifying that really wasn't your position).
>> > Influence is very relative and not only core devs have "influence".
>> > Maybe Andreas Antonopolous has more "influence" than I have because he
>> > is a more public figure?
>> > Well, that's fine I think. I don't see the point in discussing who has
>> > how much influence.
>> >
>> >> The outside influences and stake of the developer is a relevant topic.
>> >> The
>> >> same types of things are discussed on this list all the time in the
>> >> context
>> >> of miners, users, merchants, and exchanges. Again, the developers try
>> >> to
>> >> place themselves on some kind of pedestal where they are the protectors
>> >> and
>> >> pure and everyone else (miners, users, merchants) are abusers,
>> >> spammers,
>> >> attackers, scammers, cheaters, etc. It is Garzik who voluntarily made
>> >> an
>> >> issue of how many bitcoins he holds and he made that issue in the same
>> >> place
>> >> where he announces many of the technical issues. It is very relevant
>> >> that
>> >> he has a minimal stake in Bitcoin holdings yet he goes around making
>> >> major
>> >> decisions about Bitcoin and trying to dictate who is allowed to
>> >> participate
>> >> in discussions. If a core developer has minimal stake in Bitcoin yet
>> >> has
>> >> major veto power over code change that is a problem.
>> > Please, don't generalize. I don't think I put myself in any kind of
>> > pedestal.
>> > That is insulting to me and many others (you may not even know and
>> > you're insulting them).
>> > And I think my Bitcoin holdings are completely irrelevant when judging
>> > my contributions to the software: either they're good or not, and who
>> > I am or how many Bitcoins I have at any given time shouldn't matter.
>> > Again, nobody forces you to use our software, as said there's
>> > alternatives (including forking the project right now).
>> >
>> >> You are correct that you cannot give power to any person over the
>> >> Internet
>> >> which is why some kind of process needs to be developed that does not
>> >> involve trying to convince one person to make the changes or a system
>> >> that
>> >> depends on unwritten, ever-changing rules maintained by a handful of
>> >> people.
>> > Well, for now the process we have is seeking consensus, and although
>> > our definition of "uncontroversial" is very vague, I think it is quite
>> > obvious when a proposed change is not "uncontroversial" (like in the
>> > block size debate).
>> > It seems to me that any other "formal process" would imply
>> > centralization in the decision making of the consensus rules (and from
>> > there you only have to corrupt that centralized organization to
>> > destroy Bitcoin).
>> >
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> 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
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>