From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5jCA-0007LB-TB for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 23:26:06 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of riseup.net designates 198.252.153.129 as permitted sender) client-ip=198.252.153.129; envelope-from=odinn.cyberguerrilla@riseup.net; helo=mx1.riseup.net; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z5jC9-0001JQ-Ch for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 23:26:06 +0000 Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 3B5B6426AD; Thu, 18 Jun 2015 23:25:59 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla) with ESMTPSA id B093C225D7 Message-ID: <55835385.60908@riseup.net> Date: Thu, 18 Jun 2015 16:25:57 -0700 From: odinn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jeff Garzik , Mark Friedenbach References: <55828737.6000007@riseup.net> <55831CAB.2080303@jrn.me.uk> <1867667.WXWC1C9quc@crushinator> In-Reply-To: Content-Type: text/plain; charset=windows-1252 X-Virus-Scanned: clamav-milter 0.98.7 at mx1 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.7 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.252.153.129 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines -0.1 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z5jC9-0001JQ-Ch Cc: Bitcoin Development , Gavin Andresen Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 23:26:06 -0000 -----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 > > wrote: >=20 > On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik > wrote: >=20 >=20 > The whole point is getting out in front of the need, to prevent=20 > 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 =97 such as the Bitcoin core developer Jeff Garzik's BIP-100 draft =97 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 >=20 > To do that, you need to (a) plan forward, in order to (b) set a=20 > hard fork date in the future. >=20 >=20 > Or alternatively, fix the reasons why users would have negative=20 > experiences with full blocks, chiefly: >=20 > * Get safe forms of replace-by-fee and child-pays-for-parent=20 > 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. >=20 > Not raising the block size limit does not mean doing nothing to=20 > solve the problem. >=20 >=20 > 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. >=20 > It is a far, far larger amount of work to write, test and deploy > than simply increasing the block size limit. >=20 > Think through roll-out of these ambitious suggestions, before > suggesting as an alternative! >=20 > 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. >=20 >=20 >=20 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. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -- Jeff Garzik Bitcoin core developer and open source evangelist=20 > BitPay, Inc. https://bitpay.com/ >=20 >=20 > ---------------------------------------------------------------------- - -------- > >=20 >=20 >=20 > _______________________________________________ Bitcoin-development > mailing list Bitcoin-development@lists.sourceforge.net=20 > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 - --=20 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=3D =3DhBcE -----END PGP SIGNATURE-----