Re: [bitcoin-dev] Bitcoin XT 0.11A

[Michael Naber <mickeybob@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 11762 bytes --]

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 <mark@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 <elombrozo@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
>
>

[-- Attachment #2: Type: text/html, Size: 15300 bytes --]