Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Eric Lombrozo <elombrozo@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 --]