From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5iNF-0004oR-F2 for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 22:33:29 +0000 X-ACL-Warn: Received: from mail-ig0-f178.google.com ([209.85.213.178]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5iNC-0004Oz-Q2 for bitcoin-development@lists.sourceforge.net; Thu, 18 Jun 2015 22:33:29 +0000 Received: by igblz2 with SMTP id lz2so1940738igb.1 for ; Thu, 18 Jun 2015 15:33:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4ybQTEN7Nei36eZrOtrf3SE8nfGsfB5YeD+TXB6ETzA=; b=l6FHnqoFp50HHpEzjjYLr3q73e0+otq/9Scv3rN5xn+6eOvsP5hYLJqeT6idOgokxL lvqlr6ZjfGEeEBg62WnVP/C/tSslxQ5Sug9P7DsL5Uutg/KBKcF6O29lq5qCXSnx9eFM rA8k4jVUF6WQWJpMOK39DmDYM/JqlaJ1nv0y/GuxQF3LsnD8EeCyccIbjW7WULsqCiN6 wC2xZiPzPeI8xaI/f2K3dIcSCGAf8Pu0pXFV9c6s8EAy9zEe4R4ySqlAN7elCOITUHJN gUTFQOmQg2ki6QPKwju8Ub0N3jNG+dgyDpI/dG9jqm8gLm6/QPnZ4AUqdsnJgvdyA7xU 9X9A== X-Gm-Message-State: ALoCoQk3RqU4apPvwNQwN3xi8IFR4hM1S8JiXmbDcBAr5OGG844cE0RIR/uWWCE4pm4iUBGTYoRC X-Received: by 10.107.37.69 with SMTP id l66mr18264011iol.76.1434666801410; Thu, 18 Jun 2015 15:33:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.149.20 with HTTP; Thu, 18 Jun 2015 15:33:00 -0700 (PDT) X-Originating-IP: [24.4.96.213] In-Reply-To: References: <55828737.6000007@riseup.net> <55831CAB.2080303@jrn.me.uk> <1867667.WXWC1C9quc@crushinator> From: Mark Friedenbach Date: Thu, 18 Jun 2015 15:33:00 -0700 Message-ID: To: Jeff Garzik Content-Type: multipart/alternative; boundary=001a1140ea0211caa10518d265d1 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Z5iNC-0004Oz-Q2 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 22:33:29 -0000 --001a1140ea0211caa10518d265d1 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik wrote: > > The whole point is getting out in front of the need, to prevent > significant negative impact to users when blocks are consistently full. > > 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. --001a1140ea0211caa10518d265d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik <jgarzik@bi= tpay.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.

To do= that, you need to (a) plan forward, in order to (b) set a hard fork date i= n the future.

Or alternatively,= fix the reasons why users would have negative experiences with full blocks= , chiefly:

=C2=A0 * Get safe forms of replace-by-fee and = child-pays-for-parent finished and in 0.12.
=C2=A0 * Develop = cross-platform libraries for managing micropayment channels, and get wallet= authors to adopt
=C2=A0 * Use fidelity bonds, solvency proo= fs, and other tricks to minimize the risk of already deployed off-chain sol= utions as an interim measure until:
=C2=A0 * 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.

--001a1140ea0211caa10518d265d1--