š
Original date posted:2015-06-19
š Original message: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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/b98d2d71/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150618/b98d2d71/attachment.sig>;
