public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ken Friece <kfriece@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bitcoin XT 0.11A
Date: Sat, 15 Aug 2015 18:28:15 -0400	[thread overview]
Message-ID: <CAKujSOGdXoo4DORHtD7KV1fgjHzvcSQnUr=yNL4ruKhn1Lwjig@mail.gmail.com> (raw)
In-Reply-To: <CC1B6D0E-F9D5-422B-980D-C589CDC00612@gmail.com>

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

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
>
>
>

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

  parent reply	other threads:[~2015-08-15 22:28 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-15 17:02 [bitcoin-dev] Bitcoin XT 0.11A Mike Hearn
2015-08-15 17:57 ` s7r
2015-08-15 18:38 ` s7r
2015-08-15 19:21   ` Mike Hearn
2015-08-15 20:36     ` Milly Bitcoin
2015-08-15 20:47       ` Bryan Bishop
2015-08-15 21:10         ` Milly Bitcoin
2015-08-15 20:55       ` Micha Bailey
2015-08-15 21:32 ` Eric Lombrozo
2015-08-15 22:01   ` Ken Friece
2015-08-15 22:16     ` Eric Lombrozo
2015-08-15 22:27       ` Angel Leon
2015-08-15 22:28       ` Ken Friece [this message]
2015-08-15 22:55         ` Mark Friedenbach
2015-08-15 23:04           ` Ken Friece
2015-08-15 23:07             ` Eric Lombrozo
2015-08-15 23:30               ` Michael Naber
2015-08-15 23:40               ` Mark Friedenbach
2015-08-15 23:57                 ` Ken Friece
2015-08-16  0:06                 ` Milly Bitcoin
2015-08-16 13:49   ` Mike Hearn
2015-08-16 15:44     ` Anthony Towns
2015-08-16 16:07     ` Tamas Blummer
2015-08-16 16:12       ` Levin Keller
2015-08-16 17:01       ` Adam Back
2015-08-16 18:15         ` Tamas Blummer
2015-08-16 20:27 ` Eric Voskuil
2015-08-15 22:39 muyuubyou
2015-08-16 18:37 ` Andrew LeCody
2015-08-16 23:02 ` Cameron Garnham
2015-08-16 23:22   ` Andrew LeCody
2015-08-17  0:03     ` Cameron Garnham
2015-08-17  6:42       ` Peter Todd
2015-08-17 12:29         ` Andrew LeCody
2015-08-17 12:33           ` Eric Lombrozo
2015-08-19 10:09             ` Jorge Timón
2015-08-19 15:41               ` s7r
2015-08-19 22:28                 ` Jorge Timón
2015-08-19 22:45                   ` Adam Back
2015-08-19 23:23                     ` Peter Todd
2015-08-20 10:25                   ` s7r
2015-08-20 11:32                     ` Milly Bitcoin
2015-08-20 11:46                       ` Hector Chu
2015-08-20 12:29                         ` Milly Bitcoin
2015-08-20 14:25                           ` Tamas Blummer
2015-08-17 21:42     ` Matt Corallo
2015-08-16  2:08 muyuubyou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKujSOGdXoo4DORHtD7KV1fgjHzvcSQnUr=yNL4ruKhn1Lwjig@mail.gmail.com' \
    --to=kfriece@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox