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 

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 

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 <ctpa...@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: signature.asc
Description: Message signed with OpenPGP using GPGMail

Bitcoin-development mailing list

Reply via email to