From: Eric Lombrozo <elombrozo@gmail•com>
To: Chris Pacia <ctpacia@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Date: Thu, 18 Jun 2015 22:59:38 -0700 [thread overview]
Message-ID: <CC9CB30F-EA9A-49F9-AA24-92C588F8A3F3@gmail.com> (raw)
In-Reply-To: <55836916.6040002@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5272 bytes --]
I don’t 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’t really about addressing basic scalability concerns - for that we’ll clearly need architectural and algorithmic improvements…and will likely need to move to a model where it isn’t necessary for everyone to validate everyone else’s latte purchases. Larger blocks might, at best, keep the current system chugging along temporarily - although I’m not sure that’s necessarily such a great thing…we 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…but without real market pressures, I’m 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.
——
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…but it is NOT the only implementation…and it wasn’t 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…a 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…although this doesn’t 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…by 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…yes, it can be frustratingly slow…I’ve tried to push for many changes to the Bitcoin network…and have only succeeded a very small number of times. And yes, it’s often been quite frustrating. But trying to unilaterally impose a change of consensus rules for an existing cryptoledger sets a horrendous precedent…this isn’t 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:
>
> 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-development
[-- Attachment #1.2: Type: text/html, Size: 7089 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
next prev parent reply other threads:[~2015-06-19 5:59 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-18 8:54 odinn
2015-06-18 10:00 ` Mike Hearn
2015-06-18 11:14 ` Wladimir J. van der Laan
2015-06-18 11:47 ` Wladimir J. van der Laan
2015-06-18 13:36 ` Mike Hearn
2015-06-18 15:58 ` Gregory Maxwell
2015-06-18 12:29 ` Pieter Wuille
2015-06-18 12:50 ` Wladimir J. van der Laan
2015-06-18 12:56 ` Benjamin
2015-06-18 13:49 ` Mike Hearn
2015-06-18 14:05 ` Wladimir J. van der Laan
2015-06-18 14:16 ` Mike Hearn
2015-06-18 14:53 ` Milly Bitcoin
2015-06-18 14:56 ` Jeff Garzik
2015-06-18 15:13 ` Milly Bitcoin
2015-06-18 14:53 ` Jeff Garzik
2015-06-18 16:07 ` justusranvier
2015-06-18 16:28 ` Jeff Garzik
2015-06-18 17:04 ` justusranvier
2015-06-18 17:42 ` Alex Morcos
2015-06-18 18:01 ` Milly Bitcoin
2015-06-18 18:23 ` Gavin Andresen
2015-06-18 18:44 ` Alex Morcos
2015-06-18 18:49 ` Jorge Timón
2015-06-18 19:31 ` Ross Nicoll
2015-06-18 21:42 ` Matt Whitlock
2015-06-18 21:49 ` Mark Friedenbach
2015-06-18 21:58 ` Jeff Garzik
2015-06-18 22:33 ` Mark Friedenbach
2015-06-18 22:52 ` Jeff Garzik
2015-06-18 23:25 ` odinn
2015-06-18 23:16 ` Ross Nicoll
2015-06-19 0:57 ` Chris Pacia
2015-06-19 5:59 ` Eric Lombrozo [this message]
2015-06-19 9:37 ` Mike Hearn
2015-06-19 9:53 ` Benjamin
2015-06-19 10:08 ` GC
2015-06-19 10:19 ` Mike Hearn
2015-06-19 10:52 ` Eric Lombrozo
2015-06-19 11:31 ` Jorge Timón
2015-06-19 12:26 ` GC
2015-06-19 11:48 ` Brooks Boyd
2015-06-21 14:45 ` Owen Gunden
2015-06-18 21:55 ` Ross Nicoll
2015-06-18 19:24 ` Matt Corallo
2015-06-18 19:32 ` Gregory Maxwell
2015-06-18 12:38 ` Milly Bitcoin
2015-06-18 13:31 ` Mike Hearn
2015-06-18 13:50 ` Pieter Wuille
2015-06-18 15:03 ` Mark Friedenbach
2015-06-18 15:30 ` Milly Bitcoin
2015-06-18 15:46 ` Wladimir J. van der Laan
2015-06-18 16:05 ` Mike Hearn
2015-06-18 16:20 ` Wladimir J. van der Laan
2015-06-18 22:49 ` odinn
2015-06-18 16:11 ` Milly Bitcoin
2015-06-18 11:41 ` Lawrence Nahum
2015-06-18 14:33 ` Bryan Bishop
2015-06-18 18:09 ` Melvin Carvalho
2015-06-18 22:10 ` odinn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CC9CB30F-EA9A-49F9-AA24-92C588F8A3F3@gmail.com \
--to=elombrozo@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=ctpacia@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox