rich1.0npub1rslmeackq2vlwkzte3g5rc23960qkxnc3rfd7hvgne4plz5udfysayxqf2https://nostr.ae/npub1rslmeackq2vlwkzte3g5rc23960qkxnc3rfd7hvgne4plz5udfysayxqf2njumphttps://nostr.ae📅 Original date posted:2015-08-15 📝 Original message: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 <elombrozo at gmail.com> wrote: > > On Aug 15, 2015, at 3:01 PM, Ken Friece via bitcoin-dev < > bitcoin-dev at 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 at 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 at 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 at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150815/9d78087a/attachment.html>