Bitcoin has no elections; it has no courts. If not through attempting a hard-fork, how should we properly resolve irreconcilable disagreements?
On Sat, Aug 15, 2015 at 6:07 PM, Eric Lombrozo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Please take the lightning 101 discussion to another thread. > > The main point I was trying to make was that Mike is clearly > misrepresenting the views of a great number of people who have deep, > intimate knowledge of how things work and are almost certainly not > primarily motivated by their own potential for profits. > > On Aug 15, 2015, at 4:04 PM, Ken Friece via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Being an early hub provider would be an obvious place to start > capitalizing on lightning. Early lightning adopters would be in the best > position to do this. > > Long term, Bitcoin needs to scale the blockchain in a reasonable manner > and implement things like lightning. > > Limiting the blocksize is a blatant conflict of interest because it > creates artificial demand for lightning that would not otherwise exist if > the blockchain scaled in a reasonable manner. > > On Sat, Aug 15, 2015 at 6:55 PM, Mark Friedenbach <m...@friedenbach.org> > wrote: > >> I would like very much to know how it is that we're supposed to be making >> money off of lightning, and therefore how it represents a conflict of >> interest. Apparently there is tons of money to be made in releasing >> open-source protocols! I would hate to miss out on that. >> >> We are working on lightning because Mike of all people said, essentially, >> " if you're so fond of micro payment channels, why aren't you working on >> them?" And he was right! So we looked around and found the best proposal >> and funded it. >> On Aug 15, 2015 3:28 PM, "Ken Friece via bitcoin-dev" < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> I know full well who works for Blockstream and I know you're not one of >>> those folks. The Blockstream core devs are very vocal against a reasonable >>> blocksize increase (17% growth per year in Pieter's BIP is not what I >>> consider reasonable because it doesn't come close to keeping with >>> technological increases). I think we can both agree that more on-chain >>> space means less demand for lightning, and vice versa, which is a blatant >>> conflict of interest. >>> >>> I'm also trying to figure out how things like lightning are not >>> competing directly with miners for fees. More off-chain transactions means >>> less blockchain demand, which would lower on-chain fees. I'm not sure what >>> is controversial about that statement. >>> >>> The lightning network concept is actually a brilliant way to take fees >>> away from miners without having to make any investment at all in SSH-256 >>> ASIC mining hardware. >>> >>> On Sat, Aug 15, 2015 at 6:16 PM, Eric Lombrozo <elombr...@gmail.com> >>> wrote: >>> >>>> >>>> On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev < >>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>>> >>>> What are you so afraid of, Eric? If Mike's fork is successful, >>>> consensus is reached around larger blocks. If it is rejected, the status >>>> quo will remain for now. Network consensus, NOT CORE DEVELOPER CONSENSUS, >>>> is the only thing that matters, and those that go against network consensus >>>> will be severely punished with complete loss of income. >>>> >>>> >>>> I fully agree that core developers are not the only people who should >>>> have a say in this. But again, we’re not talking about merely forking some >>>> open source project - we’re talking about forking a ledger representing >>>> real assets that real people are holding…and I think it’s fair to say that >>>> the risk of permanent ledger forks far outweighs whatever benefits any >>>> change in the protocol might bring. And this would be true even if there >>>> were unanimous agreement that the change is good (which there clearly IS >>>> NOT in this case) but the deployment mechanism could still break things. >>>> >>>> If anything we should attempt a hard fork with a less contentious >>>> change first, just to test deployability. >>>> >>>> I'm not sure who appointed the core devs some sort of Bitcoin Gods that >>>> can hold up any change that they happen to disagree with. It seems like the >>>> core devs are scared to death that the bitcoin network may change without >>>> their blessing, so they go on and on about how terrible hard forks are. >>>> Hard forks are the only way to keep core devs in check. >>>> >>>> >>>> Again, let’s figure out a hard fork mechanism and test it with a far >>>> less contentious change first >>>> >>>> Despite significant past technical bitcoin achievements, two of the >>>> most vocal opponents to a reasonable blocksize increase work for a company >>>> (Blockstream) that stands to profit directly from artificially limiting the >>>> blocksize. The whole situation reeks. Because of such a blatant conflict of >>>> interest, the ethical thing to do would be for them to either resign from >>>> Blockstream or immediately withdraw themselves from the blocksize debate. >>>> This is the type of stuff that I hoped would end with Bitcoin, but alas, I >>>> guess human nature never changes. >>>> >>>> >>>> For the record, I do not work for Blockstream. Neither do a bunch of >>>> other people who have published a number of concerns. Very few of the >>>> concerns I’ve seen from the technical community seem to be motivated >>>> primarily by profit motives. >>>> >>>> It should also be pointed out that *not* making drastic changes is the >>>> default consensus policy…and the burden of justifying a change falls on >>>> those who want to make the change. Again, the risk of permanent ledger >>>> forks far outweighs whatever benefits protocol changes might bring. >>>> >>>> Personally, I think miners should give Bitcoin XT a serious look. >>>> Miners need to realize that they are in direct competition with the >>>> lightning network and sidechains for fees. Miners, ask yourselves if you >>>> think you'll earn more fees with 1 MB blocks and more off-chain >>>> transactions or with 8 MB blocks and more on-chain transactions… >>>> >>>> >>>> Miners are NOT in direct competition with the lightning network and >>>> sidechains - these claims are patently false. I recommend you take a look >>>> at these ideas and understand them a little better before trying to make >>>> any such claims. Again, I do not work for Blockstream…and my agenda in this >>>> post is not to promote either of these ideas…but with all due respect, I do >>>> not think you properly understand them at all. >>>> >>>> The longer this debate drags on, the more I agree with BIP 100 and Jeff >>>> Garzik because the core devs are already being influenced by outside forces >>>> and should not have complete control of the blocksize. It's also >>>> interesting to note that most of the mining hashpower is already voting for >>>> 8MB blocks BIP100 style. >>>> >>>> >>>> I don’t think the concern here is so much that some people want to >>>> increase block size. It’s the *way* in which this change is being pushed >>>> that is deeply problematic. >>>> >>>> On Sat, Aug 15, 2015 at 5:32 PM, Eric Lombrozo via bitcoin-dev < >>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>>> >>>>> You deeply disappoint me, Mike. >>>>> >>>>> Not only do you misrepresent many cogent, well thought out positions >>>>> from a great number of people who have published and posted a number of >>>>> articles detailing an explaining in-depth technical concerns…you also seem >>>>> to fancy yourself more capable of reading into the intentions of someone >>>>> who disappeared from the scene years ago, before we even were fully aware >>>>> of many things we now know that bring the original “plan” into question. >>>>> >>>>> I ask of you, as a civilized human being, to stop doing this divisive >>>>> crap. Despite your protestations to the contrary, YOU are the one who is >>>>> proposing a radical departure from the direction of the project. Also, as >>>>> several of us have clearly stated before, equating the fork of an open >>>>> source project with a fork of a cryptoledger is completely bogus - there’s >>>>> a lot of other people’s money at stake. This isn’t a democracy - consensus >>>>> is all or nothing. The fact that a good number of the people most >>>>> intimately familiar with the inner workings of Satoshi’s invention do not >>>>> believe doing this is a good idea should give you pause. >>>>> >>>>> Please stop using Bitcoin as your own political football…for the sake >>>>> of Bitcoin…and for your own sake. Despite your obvious technical abilities >>>>> (and I sincerely do believe you have them) you are discrediting yourself >>>>> and hurting your own reputation. >>>>> >>>>> >>>>> - Eric >>>>> >>>>> On Aug 15, 2015, at 10:02 AM, Mike Hearn via bitcoin-dev < >>>>> bitcoin-dev@lists.linuxfoundation.org> wrote: >>>>> >>>>> Hello, >>>>> >>>>> As promised, we have released Bitcoin XT 0.11A which includes the >>>>> bigger blocks patch set. You can get it from >>>>> >>>>> https://bitcoinxt.software/ >>>>> >>>>> I feel sad that it's come to this, but there is no other way. The >>>>> Bitcoin Core project has drifted so far from the principles myself and >>>>> many >>>>> others feel are important, that a fork is the only way to fix things. >>>>> >>>>> Forking is a natural thing in the open source community, Bitcoin is >>>>> not the first and won't be the last project to go through this. Often in >>>>> forks, people say there was insufficient communication. So to ensure >>>>> everything is crystal clear I've written a blog post and a kind of >>>>> "manifesto" to describe why this is happening and how XT plans to be >>>>> different from Core (assuming adoption, of course). >>>>> >>>>> The article is here: >>>>> >>>>> https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1 >>>>> >>>>> It makes no attempt to be neutral: this explains things from our point >>>>> of view. >>>>> >>>>> The manifesto is on the website. >>>>> >>>>> I say to all developers on this list: if you also feel that Core is no >>>>> longer serving the interests of Bitcoin users, come join us. We don't >>>>> bite. >>>>> >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> bitcoin-dev mailing list >>>>> bitcoin-dev@lists.linuxfoundation.org >>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>>> >>>>> >>>> _______________________________________________ >>>> bitcoin-dev mailing list >>>> bitcoin-dev@lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>>> >>>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
