Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[odinn <odinn.cyberguerrilla@riseup.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Regarding the bit on "getting out in front of the need, to prevent
significant negative impacts to users" I had suggested the following:

On 06/18/2015 03:52 PM, Jeff Garzik wrote:
> On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach
> <mark@friedenbach.org <mailto:mark@friedenbach.org>> wrote:
> 
> On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgarzik@bitpay.com 
> <mailto:jgarzik@bitpay.com>> wrote:
> 
> 
> The whole point is getting out in front of the need, to prevent 
> significant negative impact to users when blocks are consistently
> full.


My thoughts on that:

Possible scope narrowing to one of the following concepts (but please,
someone tell me if this "scope narrowing" is unwise, not timely, or if
there is some other factors that would make it just stupid right now
because other things are in the works or whatever:

~ Jeff Garzik, with respect to his BIP 100 (note Evan Mo, CEO of
Huobi's mining project Digcoin, clarified that the big Chinese mining
pools consider further adjustments to the protocol beyond the
suggested 8 MB block size limit adjustment — such as the Bitcoin core
developer Jeff Garzik's BIP-100 draft — to be feasible)
   ~ Adam Back, with a simplified soft-fork one-way peg
   ~ Gavin Andresen, developing an 8 MB block size limit adjustment in
the context of Core (as an example) with one or more of the above
authors rather than focusing on XT. (This is a big assumption but,
roll with it)

All of this assumes that developer(s) are willing to abandon
intentionally contentious proposals such as the "hard fork to XT w/ 20
MB," remain within the context of Core and be reasonable.

Here I am being aware of the fact that "Pushing a hard fork in the
face of such controversy is a folly, a danger to the network, and that
deserves to be said." - Wladimir J. van der Laan
https://github.com/bitcoin/bitcoin.org/pull/894#issuecomment-112113917


> 
> To do that, you need to (a) plan forward, in order to (b) set a 
> hard fork date in the future.
> 
> 
> Or alternatively, fix the reasons why users would have negative 
> experiences with full blocks, chiefly:
> 
> * Get safe forms of replace-by-fee and child-pays-for-parent 
> finished and in 0.12. * Develop cross-platform libraries for
> managing micropayment channels, and get wallet authors to adopt *
> Use fidelity bonds, solvency proofs, and other tricks to minimize
> the risk of already deployed off-chain solutions as an interim
> measure until: * Deploy soft-fork changes for truly scalable
> solutions like Lightning Network.
> 
> Not raising the block size limit does not mean doing nothing to 
> solve the problem.
> 
> 
> This is a long, unreasonable list of work.  None of this exists and
> it equates to "upgrade all wallets and websites everywhere"  It
> requires all exchanges, payment processors, merchants, etc. to  -
> basically everybody but miners - to update.
> 
> It is a far, far larger amount of work to write, test and deploy
> than simply increasing the block size limit.
> 
> Think through roll-out of these ambitious suggestions, before
> suggesting as an alternative!
> 
> Not a realistic alternative except in an alternate universe where
> (a) developer work at all companies is cost free, plus (b) we can
> pause the business universe while we wait for The Perfect
> Solution.
> 
> 
> 


Something else I wanted to point out here in this thread is the
subject of the problem of "developers going off the deep end" which is
what started this thread:

Suppose you have a developer with full commit access who happens to
start threatening to revoking the other developers' commit access on
the repository, or that person doesn't even threaten, one day it just
happens.

What do you have then?  Peter Todd has stated that all one "would
achieve by that sabotage is setting a key-value pair in a centralised
registry."  But is that what we want?

The answer, obviously, is no.

This leads to other questions. What technical mechanisms exist to keep
developers from (in some dubious emotional or psycho state) to just
going off the deep and doing exactly what has been described above, if
they have full commit access?  Is there a process whereby that can't
actually happen unless another developer provides a signature (e.g. a
multisignature type of process)?  What keeps bitcoin safe from "The
Hearn Threat?"

If nothing does, then how would you change that?

And go ahead and tell me if these are dumb questions and I should just
be quiet, but if they are, please do explain why they are such dumb
questions.

> 
> 
> 
> 
> 
> 
> 
> -- Jeff Garzik Bitcoin core developer and open source evangelist 
> BitPay, Inc.      https://bitpay.com/
> 
> 
> ----------------------------------------------------------------------
- --------
>
> 
> 
> 
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

- -- 
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

iQEcBAEBAgAGBQJVg1OFAAoJEGxwq/inSG8COpAIAJrH9Uj9bcKr+UUR7ePV6/Yj
MmNTY2VKAtiQhwHM+Mqk2VvQANs7/uRBdZjzGnw1NRcca/m8Q0yZUHQiP8avCUOE
3MHqGviYjfeJdu1pcf+PO2pAImM5FCFdrfbbiWUt+ZoOKTxZjsLtF4RE+mc13AXJ
dktvy6SFdvQUgEx8pdXEDpmaUSYUr7syFP4sgHZmyMlhvCsXyE/8dC3sZTzEpVnC
xy1dyBmXHPW3W4FfBSblwwWgJWMcIcGJn8OLQKK5pni/iSVL6IMoRI/MLwOJdRr4
lr83g9FR/qxMqAT9UIZtATnePlkkWPU1szvak/tU/49fGioyYOF4b4KPg/bHYSc=
=hBcE
-----END PGP SIGNATURE-----