Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.174 as permitted sender)
	client-ip=209.85.220.174; envelope-from=ctpacia@gmail.com;
	helo=mail-qk0-f174.google.com; 
Message-ID: <55836916.6040002@gmail.com>
Date: Thu, 18 Jun 2015 20:57:58 -0400
From: Chris Pacia <ctpacia@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <55828737.6000007@riseup.net>	<CABm2gDoa7KxsgvREo3yiNjfd6AeayqAqkjMe2rvX8yyxR_ddcA@mail.gmail.com>	<55831CAB.2080303@jrn.me.uk>
	<1867667.WXWC1C9quc@crushinator>	<CAOG=w-scXm-46sp2NgR2UUp20R5ujuaAzW-jU_Owh20C4Xc=9A@mail.gmail.com>	<CAJHLa0Mhnma8_ys2ckEA+dLT-EWnqO4j8YKMSaf3Tvv_K14czQ@mail.gmail.com>
	<CAOG=w-tf7qz9XSkDg5POKtFLkHWDA==jf2iVxVL8wz1hqcAVOg@mail.gmail.com>
In-Reply-To: <CAOG=w-tf7qz9XSkDg5POKtFLkHWDA==jf2iVxVL8wz1hqcAVOg@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------080005050102040202090608"
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer
 to Remove Commit Access from Other Developers
Precedence: list

This is a multi-part message in MIME format.
--------------080005050102040202090608
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

On 06/18/2015 06:33 PM, Mark Friedenbach wrote:
>
>   * 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.

One of my biggest concerns is that these solutions (lightning network in
particular) could end up being worse, in terms of decentralization, than
would be a bitcoin network using larger blocks. We don't exactly know
what the economies of scale are for pay hubs and could very well end up
with far fewer hubs than nodes at any conceivable block size.

Of course, it could also turn out to be fantastic, but it seems like an
enormous gamble to basically force everyone in the ecosystem to
collectively spend millions of dollars upgrading to Lightning /and then/
see whether it's actually an improvement in terms of decentralization.

To me, a much more sane approach would be to allow people to voluntarily
opt in to those other solutions after we've had an opportunity to
experiment with them and see how they actually function in practice, but
that can't happen if the network runs out of capacity first.


--------------080005050102040202090608
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    On 06/18/2015 06:33 PM, Mark Friedenbach wrote:<br>
    <blockquote
cite="mid:CAOG=w-tf7qz9XSkDg5POKtFLkHWDA==jf2iVxVL8wz1hqcAVOg@mail.gmail.com"
      type="cite">
      <div><br>
      </div>
      <div>  * Get safe forms of replace-by-fee and
        child-pays-for-parent finished and in 0.12.<br>
      </div>
      <div>  * Develop cross-platform libraries for managing
        micropayment channels, and get wallet authors to adopt <br>
      </div>
      <div>  * Use fidelity bonds, solvency proofs, and other tricks to
        minimize the risk of already deployed off-chain solutions as an
        interim measure until:<br>
      </div>
      <div>  * Deploy soft-fork changes for truly scalable solutions
        like Lightning Network.</div>
    </blockquote>
    <br>
    One of my biggest concerns is that these solutions (lightning
    network in particular) could end up being worse, in terms of
    decentralization, than would be a bitcoin network using larger
    blocks. We don't exactly know what the economies of scale are for
    pay hubs and could very well end up with far fewer hubs than nodes
    at any conceivable block size. <br>
    <br>
    Of course, it could also turn out to be fantastic, but it seems like
    an enormous gamble to basically force everyone in the ecosystem to
    collectively spend millions of dollars upgrading to Lightning <i>and
      then</i> see whether it's actually an improvement in terms of
    decentralization.<br>
    <br>
    To me, a much more sane approach would be to allow people to
    voluntarily opt in to those other solutions after we've had an
    opportunity to experiment with them and see how they actually
    function in practice, but that can't happen if the network runs out
    of capacity first. <br>
    <br>
  </body>
</html>

--------------080005050102040202090608--