Discussion:
Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Add Reply
odinn
2015-06-18 08:54:15 UTC
Reply
Permalink
Raw Message
Report
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Recently I saw the following video:



Hadn't seen it until just today, although it was done on June 8, 2015.
So this is a bit dated, but to me it was a bit of a stunner to see the
extreme nature of (some) of the views presented in this video.

Let me be blunt, I have serious concerns regarding threats issued by a
developer in this video, and I think that it is entirely possible that
those of you who are core developers have already seen this and have
been discussing it. But I am interested in seeing this resolved here
on this list openly and having it resolved. It's sad and unfortunate
to me, but I feel that it's necessary to do this. Identify what's
happening, address it squarely, have the person who is threatening
others explain his/her behavior, deal with the problem and move on.
This seems to be very important. Please tell me if I am wrong about
this or totally flawed in my perspective here. Go right ahead.

In this video, a particular developer makes the following statement,
stating in part:

"My preferred solution is that Gavin revokes commit access from
everyone else in the project, and then... makes the change himself"

Regardless of how you look at this, and even if we believe that Gavin
will not respond to that developer's request for a so-called
"solution," such a statement (by any developer) is indeed both a
threat and an act of sabotage against the larger bitcoin community.
We should certainly be thankful therefore, for the recent policy
change at bitcoin.org which can be seen here:
https://cloud.githubusercontent.com/assets/61096/8173297/578483f8-1399-1
1e5-8f48-96f33d12b996.png

I firmly believe that any developer who made a statement suggesting
that commit access of others in the project be revoked so that they
can proceed with their personal plan, needs to answer for having made
such a suggestion with a formal apology to this list, followed by an
explanation for why they themselves should not have their commit
access removed.

Overall, however, this sort of bombastic, nuclear suggestion makes me
seriously concerned for the future of bitcoin (as well as any
cryptocurrency which has repositories on Github).

So, you know who you are: Apologize for your statement ("preferred
solution") and explain to the community why you should still have
commit access in light of the threat you have made to all the other
developers (and indeed to all participants of the bitcoin community).
These "nuclear options" are unacceptable to us all.

Respectfully,

- -O


- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVgoc3AAoJEGxwq/inSG8C6QYH/1Ag+4ESTSUPkP8PCTj1AJds
J4MmBz4cX7IYsSttTAjyiwd6oTHCU+wAcXtgZYpzr8rWF62bG5/+kAFUfjKwNsGM
WqcdNOR6h8fQulx8niuro8kZF/xOsG5eHtRK2FMCorxj0t6qn4pH5WAQL73J3hXQ
xI831Nt/L7VTa0jlKbr2/VGlqh6CtGrZ9mXp6aV1MBNwHbFryNBJW9ubvUv/IRxZ
GyJ+c3+Br2KKAQTMsyNn3VXMlXJL6kt0pwwk2od3j/+dKE4pAetHvZ5OgIO+qUWd
6R0/AaoW5jk343TaQ5BHaSpNW+OM9Yc1ycZyqE/YV8JwWeA6G/QdmRVYeoLMCZQ=
=zJeO
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Mike Hearn
2015-06-18 10:00:17 UTC
Reply
Permalink
Raw Message
Report
Dude, calm down. I don't have commit access to Bitcoin Core and Gavin
already said long ago he wouldn't just commit something, even though he has
the ability to do so.

So why did I say it? Because it's consistent with what I've always said:
you cannot run a codebase like Wikipedia. Maintainers have to take part in
debates, and then make a decision, and anyone else who was delegated commit
access for robustness or convenience must then respect that decision. It's
the only way to keep a project making progress at a reasonable pace.

This is not a radical position. That's how nearly all coding projects work.
I have been involved with open source for 15 years and the 'single
maintainer who makes decisions' model is normal, even if in some large
codebases subsystems have delegated submaintainers.

This is also how all my own projects are run. Bitcoinj has multiple people
with commit access. Regardless, if there were to be some design dispute or
whatever, I wouldn't tolerate the others with commit access starting some
kind of Wiki-style edit war in the code if they disagreed. Nor would I ever
expect to get my own way in other people's projects by threatening to
revert the maintainers changes.

Core is in the weird position where there's no decision making ability at
all, because anyone who shows up and shouts enough can generate
'controversy', then Wladimir sees there is disagreement and won't touch the
issue in question. So it just runs and runs and *anyone* with commit access
can then block any change.

I realise some people think this anti-process leads to better decision
making. I disagree. It leads to no decision making, which is not the same
thing at all.
Wladimir J. van der Laan
2015-06-18 11:14:09 UTC
Reply
Permalink
Raw Message
Report
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Post by Mike Hearn
Core is in the weird position where there's no decision making ability at
all, because anyone who shows up and shouts enough can generate
'controversy', then Wladimir sees there is disagreement and won't touch the
issue in question. So it just runs and runs and *anyone* with commit access
can then block any change.
Bitcoin Core is completely different from your average open source project in one aspect: where it concerns consensus.

Like in any open source project there is lots of decision making ability for code changes. I'd say look at the changelog for e.g. 0.11 https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log, or follow pull requests for a while, to see how many decisions about changes are made from day to day. No, I'm not sitting on my hands, and so is none of the other contributors that you'd like to get rid of.

Consensus changes are *much* more difficult, on the other hand. Even relatively straightforward softforks come with a long discussion process (see BIP62, BIP66). A hardfork is hard to do at the best of times (everyone needs to upgrade their software!), and simply not possible if almost the entire technical community disagrees with you.

Bitcoin is supposed to be a robust, global, decentralized network beyond anyone's control. It makes *no sense* to try to run it as a dictatorship. This would create a handy central position where power can be applied, pushing through changes to the behavior of the system, either by force or other ways of motivation. I refuse to take part in that.

Hence, anything that is controversial needs to be considered really carefully. If I suddenly start making changes to the consensus code without full agreement, by all means take away my commit privileges.

(a major reason for the ongoing libconsensus work is to separate "Bitcoin Core, the node software" and "The Bitcoin Consensus" along clear lines, to avoid this kind of nasty confusion)

Wladimir
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJVgqfOAAoJEHSBCwEjRsmmFT8H/Rkm29AhLhT8R1Vx8oKUIzID
+NB7tOps3lIilkDQIC5zHSknx5iugrrAdRf1w7qPj/o8+xhCZw9ruu8eIq+djkRQ
tvzbHil2pqgT3VHriRlY4lvlmu2NmBcYrAuX9sDhUHBo6cwGajfKMJPfE0haK3K4
7EmfdGXJYJmiBnhE6ikOiU687M2WgsmIGrBDIxeA5wYwVK9Ph8hfcbuj7AHvIMI9
ZNU/V6uhcTjn5wT+6DHGIOxHipYHyAwKb7jKho0XkM6Yi4ORe1mxF5HDtqA0ztta
mZPNjNrt/ngK20xRbqkb0GtxoyZq38ZF3Bq1gaWl2v9MBBMD5ZxQAvgCNUQFEo0=
=W26K
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Wladimir J. van der Laan
2015-06-18 11:47:59 UTC
Reply
Permalink
Raw Message
Report
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Post by Mike Hearn
Core is in the weird position where there's no decision making ability at
all, because anyone who shows up and shouts enough can generate
'controversy', then Wladimir sees there is disagreement and won't touch the
issue in question. So it just runs and runs and *anyone* with commit access
can then block any change.
And allegations that the project is "run like wikipedia" or "an edit war" are verifyably untrue.
Check the commit history.
How many reverts do you see? How many of those do you see that are not simply to get rid of unexpected bugs, to be re-merged later?

Not much more than two, in ~5500 commit over six years. I feel sorry for you that `getutxos` was rejected in a messy way, still you are so held up about it and keep repeating it as if it is a daily occurence. Disingenuous, at the least.

Wladimir
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJVgq/WAAoJEHSBCwEjRsmm8NUIAI/csucOmfF9e+BtSH+uruhl
ox32stQfD3hwcKropLEPFfKvmOcRU1nXBy6lcvhG+axw+WqpC48EvpD73P/BuSv7
RvlLayqP+D6oiNsH+7S7C0/ndy+Pne04D+srSSBhXKfZMqruBqmUSontziJZTeLR
C6CCFwFSAvSXGV873I3i4M4U5QqIrE5PyuK75wjl2SFisd2LjBgfzZh4HDbz85Qr
gApLpdTxu4gDkGx4B9txCkfyb5W2z8nawWYb7+O7y/NbFL1Qlb36MzGuVKL6Zj1z
B8kJrOLVW9ItduVRY/03wLsqBuGC9fjuhWexjKenvMpxfO//VvOxIBA7sCDrxjU=
=lisE
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Pieter Wuille
2015-06-18 12:29:42 UTC
Reply
Permalink
Raw Message
Report
Post by Wladimir J. van der Laan
Like in any open source project there is lots of decision making ability
for code changes. I'd say look at the changelog for e.g. 0.11
https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log,
or follow pull requests for a while, to see how many decisions about
changes are made from day to day. No, I'm not sitting on my hands, and so
is none of the other contributors that you'd like to get rid of.
The analogy goes further even. Even though I disagree with some of the
changes you're making, I respect Mike's (and anyone's) right to make a fork
of Bitcoin Core. That's how open source works: if people disagree with
Post by Wladimir J. van der Laan
Consensus changes are *much* more difficult, on the other hand. Even
relatively straightforward softforks come with a long discussion process
(see BIP62, BIP66). A hardfork is hard to do at the best of times (everyone
needs to upgrade their software!), and simply not possible if almost the
entire technical community disagrees with you.
Consensus changes - in particular hardforks - are not about making a change
to the software. You are effectively asking users of the system to migrate
to a new system. Perhaps one which is a philosophical successor to the old
one, but a different system, with new rules that are incompatible with the
old one.

I believe this is something that can only be done if there is no
controversy about the change, for different reasons:

* Risk: no matter how you determine the switchover date, there is no way of
knowing when (and whether at all) everyone changes their full nodes (and
perhaps other software), and even very high hash power votes cannot prevent
an actual fork from appearing afterwards. At best, people lose the
guarantee that their confirmations are meaningful (because at some point it
becomes clear that the other side will get adopted, and they need to
switch). At worst, a fork persists, and two partitions appear, in each of
which you can spend every pre-existing coin. This defeats the primary
purpose Bitcoin was designed for: double spend protection.

* Philosophy: Bitcoin is not a democracy. The full node security model is
designed to minimize trust in other parties in the system. This works by
validating as much as possible according to the consensus rules. In
particular, there is no "majority vote" that can override things (contrary
to what some people think, it is not "longest chain wins, and a majority of
miners decide"; even a majority of miners cannot steal your coins or
produce more than the allowed subsidy, unless they convince others to
change their software). Changing the rules should be possible if there is
wide consensus, but nobody should feel forced to change their code against
their will.

* Governance: being able to push for a controversial change to the system
sets an incredibly dangerous precedent about who is in charge of the
system's rules. What if next time it is a change demanded by parties with
less good intentions (and yes, I believe people in this discussions all
have good intentions to improve the system in a way they think is most
useful)? I can promise you that I will say anything in mail to this list if
someone points a gun at me, and I think you should make the same assumption
about other people here. By avoiding controversial changes, you avoid
external and potentially invisible manipulation.

Of course, sometimes changes to the consensus rules may be wanted. The
presence of a bug is a good reason, and widespread agreement about one of
the system's limitation is too. As I said before, I think technological
growth in network bandwidth, processing power, and storage, are a good
reason why the system should be able to scale proportionally. I think there
are good technical and economic reasons why we should be cautious about
this, but the primary requirement is consensus, and aligning people's
expectation about what they can expect from network's evolution.
--
Pieter
Lawrence Nahum
2015-06-18 11:41:01 UTC
Reply
Permalink
Raw Message
Report
It's the only way to keep a project making progress at a reasonable pace.
[SNIP]

If Bitcoin is managed with a linux kernel style dictator it would be
centralized (yet unlike linux, where people can fork without impacting others
in Bitcoin a hard fork puts at risks everyone's bitcoins) - I hope we all
agree there is no point in a centralized Bitcoin?

In addition and more importantly, it would put Gavin in tremendous dangers,
both from violent threats/blackmailing prospective as well as regulatory
prospective - how can you not see that?

I hope all this confrontation will be worth something in the end: to show
that Bitcoin can't be changed centrally and that it can't be changed without
consensus


------------------------------------------------------------------------------
Loading...