path: root/3b/fd0731dfb52e1f8f76e2640e168adab754e236

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <elombrozo@gmail.com>) id 1Z5pLE-0005jv-LV
	for bitcoin-development@lists.sourceforge.net;
	Fri, 19 Jun 2015 05:59:52 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.181 as permitted sender)
	client-ip=209.85.192.181; envelope-from=elombrozo@gmail.com;
	helo=mail-pd0-f181.google.com; 
Received: from mail-pd0-f181.google.com ([209.85.192.181])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z5pLD-0005e0-3Q
	for bitcoin-development@lists.sourceforge.net;
	Fri, 19 Jun 2015 05:59:52 +0000
Received: by pdjn11 with SMTP id n11so83429711pdj.0
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 18 Jun 2015 22:59:45 -0700 (PDT)
X-Received: by 10.68.68.167 with SMTP id x7mr6440546pbt.161.1434693585339;
	Thu, 18 Jun 2015 22:59:45 -0700 (PDT)
Received: from [192.168.1.102] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202])
	by mx.google.com with ESMTPSA id de2sm9917879pdb.15.2015.06.18.22.59.40
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Thu, 18 Jun 2015 22:59:43 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_58B220C3-DC09-455B-AF16-D15F0E00F7C3";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <55836916.6040002@gmail.com>
Date: Thu, 18 Jun 2015 22:59:38 -0700
Message-Id: <CC9CB30F-EA9A-49F9-AA24-92C588F8A3F3@gmail.com>
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>
	<55836916.6040002@gmail.com>
To: Chris Pacia <ctpacia@gmail.com>
X-Mailer: Apple Mail (2.2098)
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(elombrozo[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Z5pLD-0005e0-3Q
Cc: bitcoin-development@lists.sourceforge.net
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 19 Jun 2015 05:59:52 -0000


--Apple-Mail=_58B220C3-DC09-455B-AF16-D15F0E00F7C3
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_9CEB0436-3461-4B6C-BE0A-E6FCEE21E981"


--Apple-Mail=_9CEB0436-3461-4B6C-BE0A-E6FCEE21E981
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I don=92t think the issue is between larger blocks on the one hand and =
things like lightning on the other - these two ideas are quite =
orthogonal.

Larger blocks aren=92t really about addressing basic scalability =
concerns - for that we=92ll clearly need architectural and algorithmic =
improvements=85and will likely need to move to a model where it isn=92t =
necessary for everyone to validate everyone else=92s latte purchases. =
Larger blocks might, at best, keep the current system chugging along =
temporarily - although I=92m not sure that=92s necessarily such a great =
thing=85we need to create a fee market sooner or later, and until we do =
this, block size issues will continue to crop up again and again and =
economic incentives will continue to be misplaced. It would be nice to =
have more time to really develop a good infrastructure for this=85but =
without real market pressures, I=92m not sure it will happen at all. =
Necessity is the mother of invention, after all. The question is how to =
introduce a fee market smoothly and with the overwhelming consensus of =
the community - and that's where it starts to get tricky.

=97=97

On a separate note, as several others have pointed out in this thread =
(but I wanted to add my voice to this as well), maintenance of source =
code repositories is NOT the real issue here. The bitcoin/bitcoin =
project on github is a reference implementation of the Satoshi =
protocol=85but it is NOT the only implementation=85and it wasn=92t =
really meant to be. Anyone is free to fork it, extend it, improve upon =
it, or create an entirely new network with its own genesis block=85a =
separate cryptoledger.

The real issue regarding XT is NOT the forking of source code nor issues =
surrounding commit access to repositories. The real issue is the =
*forking of a cryptoledger*.

Open source repositories are meant to be forked - in fact, it is often =
encouraged. It is also encouraged that improvements be submitted for =
review and possibly merged back into the parent repository=85although =
this doesn=92t always happen.

However, we currently have no mechanisms in place to support merging of =
forked cryptoledgers. Software, and most other forms of digital content, =
generally increases in value with more copies made. However, money is =
scarce=85by design. The entire value of the assets of a decentralized =
cryptoledger rests on the assumption that nobody can just unilaterally =
fork it and change the rules. Yes, convincing other people to do things =
a certain way is HARD=85yes, it can be frustratingly slow=85I=92ve tried =
to push for many changes to the Bitcoin network=85and have only =
succeeded a very small number of times. And yes, it=92s often been quite =
frustrating. But trying to unilaterally impose a change of consensus =
rules for an existing cryptoledger sets a horrendous precedent=85this =
isn=92t just about things like block size limits, which is a relatively =
petty issue by comparison.

It would be very nice to have a similar workflow with consensus rule =
evolution as we do with most other open source projects. You create a =
fork, demonstrate that your ideas are sound by implementing them and =
giving others something that works so they can review them, and then =
merge your contributions back in. However, the way Bitcoin is currently =
designed, this is unfortunately impossible to do this with consensus =
rules. Once a fork, always a fork - a.k.a. altcoins. Say what you will =
about how most altcoins are crap - at least most of them have the =
decency of starting with a clean ledger.


- Eric Lombrozo


> On Jun 18, 2015, at 5:57 PM, Chris Pacia <ctpacia@gmail.com> wrote:
>=20
> On 06/18/2015 06:33 PM, Mark Friedenbach wrote:
>>=20
>>   * 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> =
--------------------------------------------------------------------------=
----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--Apple-Mail=_9CEB0436-3461-4B6C-BE0A-E6FCEE21E981
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">I don=92t think the issue is between larger blocks on the one =
hand and things like lightning on the other - these two ideas are quite =
orthogonal.<div class=3D""><div class=3D""><br class=3D""></div><div =
class=3D"">Larger blocks aren=92t really about addressing basic =
scalability concerns - for that we=92ll clearly need architectural and =
algorithmic improvements=85and will likely need to move to a model where =
it isn=92t necessary for everyone to validate everyone else=92s latte =
purchases. Larger blocks might, at best, keep the current system =
chugging along temporarily - although I=92m not sure that=92s =
necessarily such a great thing=85we need to create a fee market sooner =
or later, and until we do this, block size issues will continue to crop =
up again and again and economic incentives will continue to be =
misplaced. It would be nice to have more time to really develop a good =
infrastructure for this=85but without real market pressures, I=92m not =
sure it will happen at all. Necessity is the mother of invention, after =
all. The question is how to introduce a fee market smoothly and with the =
overwhelming consensus of the community - and that's where it starts to =
get tricky.</div><div class=3D""><br class=3D""></div><div =
class=3D"">=97=97</div><div class=3D""><br class=3D""></div><div =
class=3D"">On a separate note, as several others have pointed out in =
this thread (but I wanted to add my voice to this as well), maintenance =
of source code repositories is NOT the real issue here. The =
bitcoin/bitcoin project on github is a reference implementation of the =
Satoshi protocol=85but it is NOT the only implementation=85and it wasn=92t=
 really meant to be. Anyone is free to fork it, extend it, improve upon =
it, or create an entirely new network with its own genesis block=85a =
separate cryptoledger.</div><div class=3D""><br class=3D""></div><div =
class=3D"">The real issue regarding XT is NOT the forking of source code =
nor issues surrounding commit access to repositories. The real issue is =
the *forking of a cryptoledger*.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Open source repositories are meant to =
be forked - in fact, it is often encouraged. It is also encouraged that =
improvements be submitted for review and possibly merged back into the =
parent repository=85although this doesn=92t always happen.</div><div =
class=3D""><br class=3D""></div><div class=3D"">However, we currently =
have no mechanisms in place to support merging of forked cryptoledgers. =
Software, and most other forms of digital content, generally increases =
in value with more copies made. However, money is scarce=85by design. =
The entire value of the assets of a decentralized cryptoledger rests on =
the assumption that nobody can just unilaterally fork it and change the =
rules. Yes, convincing other people to do things a certain way is =
HARD=85yes, it can be frustratingly slow=85I=92ve tried to push for many =
changes to the Bitcoin network=85and have only succeeded a very small =
number of times. And yes, it=92s often been quite frustrating. But =
trying to unilaterally impose a change of consensus rules for an =
existing cryptoledger sets a horrendous precedent=85this isn=92t just =
about things like block size limits, which is a relatively petty issue =
by comparison.</div><div class=3D""><br class=3D""></div><div =
class=3D"">It would be very nice to have a similar workflow with =
consensus rule evolution as we do with most other open source projects. =
You create a fork, demonstrate that your ideas are sound by implementing =
them and giving others something that works so they can review them, and =
then merge your contributions back in. However, the way Bitcoin is =
currently designed, this is unfortunately impossible to do this with =
consensus rules. Once a fork, always a fork - a.k.a. altcoins. Say what =
you will about how most altcoins are crap - at least most of them have =
the decency of starting with a clean ledger.</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div class=3D"">- =
Eric Lombrozo</div><div class=3D""><br class=3D""></div><div =
class=3D""><div class=3D""><br class=3D""><div><blockquote type=3D"cite" =
class=3D""><div class=3D"">On Jun 18, 2015, at 5:57 PM, Chris Pacia =
&lt;<a href=3D"mailto:ctpacia@gmail.com" =
class=3D"">ctpacia@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D"">
 =20
    <meta content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3D"Content-Type" class=3D"">
 =20
  <div text=3D"#000000" bgcolor=3D"#FFFFFF" class=3D"">
    On 06/18/2015 06:33 PM, Mark Friedenbach wrote:<br class=3D"">
    <blockquote =
cite=3D"mid:CAOG=3Dw-tf7qz9XSkDg5POKtFLkHWDA=3D=3Djf2iVxVL8wz1hqcAVOg@mail=
.gmail.com" type=3D"cite" class=3D"">
      <div class=3D""><br class=3D"">
      </div>
      <div class=3D"">&nbsp; * Get safe forms of replace-by-fee and
        child-pays-for-parent finished and in 0.12.<br class=3D"">
      </div>
      <div class=3D"">&nbsp; * Develop cross-platform libraries for =
managing
        micropayment channels, and get wallet authors to adopt <br =
class=3D"">
      </div>
      <div class=3D"">&nbsp; * Use fidelity bonds, solvency proofs, and =
other tricks to
        minimize the risk of already deployed off-chain solutions as an
        interim measure until:<br class=3D"">
      </div>
      <div class=3D"">&nbsp; * Deploy soft-fork changes for truly =
scalable solutions
        like Lightning Network.</div>
    </blockquote>
    <br class=3D"">
    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 class=3D"">
    <br class=3D"">
    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 =
class=3D"">and
      then</i> see whether it's actually an improvement in terms of
    decentralization.<br class=3D"">
    <br class=3D"">
    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 class=3D"">
    <br class=3D"">
  </div>

=
--------------------------------------------------------------------------=
----<br class=3D"">_______________________________________________<br =
class=3D"">Bitcoin-development mailing list<br class=3D""><a =
href=3D"mailto:Bitcoin-development@lists.sourceforge.net" =
class=3D"">Bitcoin-development@lists.sourceforge.net</a><br =
class=3D"">https://lists.sourceforge.net/lists/listinfo/bitcoin-developmen=
t<br class=3D""></div></blockquote></div><br =
class=3D""></div></div></div></body></html>=

--Apple-Mail=_9CEB0436-3461-4B6C-BE0A-E6FCEE21E981--

--Apple-Mail=_58B220C3-DC09-455B-AF16-D15F0E00F7C3
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVg6/KAAoJEJNAI64YFENU+KUP/0nEbvgSiuXT8Dqqr0Cp6mfS
n+J1XxiDqq0Sm9YKtBJ4DldTpsVu+J1Cps85Vx5XCI8lpW5Bwy9FQ68CbZbCMtbl
Z2B2OZfjSpJDsfI9VxRGbld8H437u74J0XUMZFVWSH5qlvtt/e9eXfkbpDHfbLn5
GJiHApv5YbMonW+X+E+JOAgemZ5h9gL8VGFmPFbuLDlPwgzGFjWN50JH4WAL+59n
kyh+2S+2x2zaA8lJONar8nXKQ5xRkZj2QB++LNxwOSR9c4f4XxANszwSSeyiF6Bg
TmDZd7+UgweYmwMxzvopw3vSPwe0DkoY4xZ6CNE4Oz73tbfsgkQa0YaUQItA9e4I
3R8Nbqt3RyB05Rxo6fBsbl57QHOghjNoH9pxgZINzkoq1exUE8huTVVYjCApVX9/
pzxVFvqDhfwLj5l4GjvSUCpXp22Oz3u895+5lAa0zGJK3fb6kFk1L0pxtciA+J6O
m8UjuK0nAKs3NGBSmyhY8k/SYiCVifxhz+EqZnbu3VQsA/2gMisyOyqI27SOjPGl
GRevWNmeUeOCWXqxuK0rfRsq7mFEyjUgxviJl9XYlGkHNRVW/IskjkDNLzs6p66a
fiI4L4gpyfwdpEMgEL/F34ikKl4OUpk3V2FNVIhMfTnu3B8b0iSBXt3c73V4Oqip
5R9vP0J2I30t+MaAvwdO
=t53T
-----END PGP SIGNATURE-----

--Apple-Mail=_58B220C3-DC09-455B-AF16-D15F0E00F7C3--