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 ) 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 ; 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 In-Reply-To: <55836916.6040002@gmail.com> Date: Thu, 18 Jun 2015 22:59:38 -0700 Message-Id: References: <55828737.6000007@riseup.net> <55831CAB.2080303@jrn.me.uk> <1867667.WXWC1C9quc@crushinator> <55836916.6040002@gmail.com> To: Chris Pacia 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 =20
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.

= --------------------------------------------------------------------------= ----
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-developmen= t

= --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--