From: odinn <odinn.cyberguerrilla@riseup•net>
To: Jeff Garzik <jgarzik@bitpay•com>,
Mark Friedenbach <mark@friedenbach•org>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>,
Gavin Andresen <gavin@bitcoinfoundation•org>
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Date: Thu, 18 Jun 2015 16:25:57 -0700 [thread overview]
Message-ID: <55835385.60908@riseup.net> (raw)
In-Reply-To: <CAJHLa0PG8C3LShqjY_sTiFw5K+j_vA1Bger2d8QnUVe07gTDDA@mail.gmail.com>
-----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-----
next prev parent reply other threads:[~2015-06-18 23:26 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 8:54 odinn
2015-06-18 10:00 ` Mike Hearn
2015-06-18 11:14 ` Wladimir J. van der Laan
2015-06-18 11:47 ` Wladimir J. van der Laan
2015-06-18 13:36 ` Mike Hearn
2015-06-18 15:58 ` Gregory Maxwell
2015-06-18 12:29 ` Pieter Wuille
2015-06-18 12:50 ` Wladimir J. van der Laan
2015-06-18 12:56 ` Benjamin
2015-06-18 13:49 ` Mike Hearn
2015-06-18 14:05 ` Wladimir J. van der Laan
2015-06-18 14:16 ` Mike Hearn
2015-06-18 14:53 ` Milly Bitcoin
2015-06-18 14:56 ` Jeff Garzik
2015-06-18 15:13 ` Milly Bitcoin
2015-06-18 14:53 ` Jeff Garzik
2015-06-18 16:07 ` justusranvier
2015-06-18 16:28 ` Jeff Garzik
2015-06-18 17:04 ` justusranvier
2015-06-18 17:42 ` Alex Morcos
2015-06-18 18:01 ` Milly Bitcoin
2015-06-18 18:23 ` Gavin Andresen
2015-06-18 18:44 ` Alex Morcos
2015-06-18 18:49 ` Jorge Timón
2015-06-18 19:31 ` Ross Nicoll
2015-06-18 21:42 ` Matt Whitlock
2015-06-18 21:49 ` Mark Friedenbach
2015-06-18 21:58 ` Jeff Garzik
2015-06-18 22:33 ` Mark Friedenbach
2015-06-18 22:52 ` Jeff Garzik
2015-06-18 23:25 ` odinn [this message]
2015-06-18 23:16 ` Ross Nicoll
2015-06-19 0:57 ` Chris Pacia
2015-06-19 5:59 ` Eric Lombrozo
2015-06-19 9:37 ` Mike Hearn
2015-06-19 9:53 ` Benjamin
2015-06-19 10:08 ` GC
2015-06-19 10:19 ` Mike Hearn
2015-06-19 10:52 ` Eric Lombrozo
2015-06-19 11:31 ` Jorge Timón
2015-06-19 12:26 ` GC
2015-06-19 11:48 ` Brooks Boyd
2015-06-21 14:45 ` Owen Gunden
2015-06-18 21:55 ` Ross Nicoll
2015-06-18 19:24 ` Matt Corallo
2015-06-18 19:32 ` Gregory Maxwell
2015-06-18 12:38 ` Milly Bitcoin
2015-06-18 13:31 ` Mike Hearn
2015-06-18 13:50 ` Pieter Wuille
2015-06-18 15:03 ` Mark Friedenbach
2015-06-18 15:30 ` Milly Bitcoin
2015-06-18 15:46 ` Wladimir J. van der Laan
2015-06-18 16:05 ` Mike Hearn
2015-06-18 16:20 ` Wladimir J. van der Laan
2015-06-18 22:49 ` odinn
2015-06-18 16:11 ` Milly Bitcoin
2015-06-18 11:41 ` Lawrence Nahum
2015-06-18 14:33 ` Bryan Bishop
2015-06-18 18:09 ` Melvin Carvalho
2015-06-18 22:10 ` odinn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55835385.60908@riseup.net \
--to=odinn.cyberguerrilla@riseup$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavin@bitcoinfoundation$(echo .)org \
--cc=jgarzik@bitpay$(echo .)com \
--cc=mark@friedenbach$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox