public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Levin Keller <post@levinkeller.de>
To: Eric Lombrozo <elombrozo@gmail.com>, NxtChg <nxtchg@hush.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Date: Mon, 17 Aug 2015 14:09:17 +0000	[thread overview]
Message-ID: <CAG86ZOxWBMaBKzgRUp=Q5TvaT1v3OjNRFx2Xofd4FdLvpg9dGQ@mail.gmail.com> (raw)
In-Reply-To: <64C86292-6671-4729-8A77-63C081797F62@gmail.com>

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

Eric Lombrozo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
schrieb am Mo., 17. Aug. 2015 um 16:03 Uhr:

> NxtChg,
>
> In the entire history of Bitcoin we’ve never attempted anything even
> closely resembling a hard fork like what’s being proposed here.
>
> Many of us have wanted to push our own hard-forking changes to the
> protocol…and have been frustrated because of the inability to do so.
>
> This inability is not due to any malice on anyone’s part…it is a feature
> of Satoshi’s protocol. For better or worse, it is *very hard* to change the
> rules…and this is exactly what imbues Bitcoin with one of its most powerful
> attributes: very well-defined settlement guarantees that cannot be suddenly
> altered nor reversed by anyone.
>
> We’ve managed to have a few soft forks in the past…and for the most part
> these changes have been pretty uncontroversial…or at least, they have not
> had nearly the level of political divisiveness that this block size issue
> is having. And even then, we’ve encountered a number of problems with these
> deployments that have at times required goodwill cooperation between
> developers and mining pool operators to fix.
>
> Again, we have NEVER attempted anything even remotely like what’s being
> proposed - we’ve never done any sort of hard fork before like this. If even
> fairly uncontroversial soft forks have caused problems, can you imagine the
> kinds of potential problems that a hard fork over some highly polarizing
> issue might raise? Do you really think people are going to want to
> cooperate?!?
>
> I can understand that some people would like bigger blocks. Other people
> might want feature X, others feature Y…and we can argue the merits of this
> or that to death…but the fact remains that we have NEVER attempted any hard
> forking change…not even with a simple, totally uncontroversial no-brainer
> improvement that would not risk any sort of ill-will that could hamper
> remedies were it not to go as smoothly as we like. *THIS* is the
> fundamental problem - the whole bigger block thing is a minor issue by
> comparison…it could be any controversial change, really.
>
> Would you want to send your test pilots on their first flight…the first
> time an aircraft is ever flown…directly into combat without having tested
> the plane? This is what attempting a hard fork mechanism that’s NEVER been
> done before in such a politically divisive environment basically amounts
> to…but it’s even worse. We’re basically risking the entire air force (not
> just one plane) over an argument regarding how many seats a plane should
> have that we’ve never flown before.
>
> We’re talking billlions of dollars’ worth of other people’s money that is
> on the line here. Don’t we owe it to them to at least test out the system
> on a far less controversial, far less divisive change first to make sure we
> can even deploy it without things breaking? I don’t even care about the
> merits regarding bigger blocks vs. smaller blocks at this point, to be
> quite honest - that’s such a petty thing compared to what I’m talking about
> here. If we attempt a novel hard-forking mechanism that’s NEVER been
> attempted before (and which as many have pointed out is potentially fraught
> with serious problems) on such a politically divisive, polarizing issue,
> the result is each side will refuse to cooperate with the other out of
> spite…and can easily lead to a war, tanking the value of everyone’s assets
> on both chains. All so we can process 8 times the number of transactions we
> currently do? Even if it were 100 times, we wouldn’t even come close to
> touching big payment processors like Visa. It’s hard to imagine a protocol
> improvement that’s worth the risk.
>
> I urge you to at least try to see the bigger picture here…and to
> understand that nobody is trying to stop anyone from doing anything out of
> some desire for maintaining control - NONE of us are able to deploy hard
> forks right now without facing these problems. And different people
> obviously have different priorities and preferences as to which of these
> changes would be best to do first. This whole XT thing is essentially
> giving *one* proposal special treatment above those that others have
> proposed. Many of us have only held back from doing this out of our belief
> that goodwill amongst network participants is more important than trying to
> push some pet feature some of us want.
>

Yadayadayada.

If someone could threaten the network by releasing a hard-forking bitcoind
version, then already all is lost. Bitcoins stability does not (and cannot)
depend on the "good will" of anyone. If it would, we should all abandon
this silly project. Relying on the good will of people is the worst idea
one could have.

So please (please please) go ahead and release your hardforking bitcoinds
you have been holding back. Competition is everything.

Cheers

Levin


>
> Please stop this negativity - we ALL want the best for Bitcoin and are
> doing our best, given what we understand and know, to do what’s right.
>
>
>
> > On Aug 17, 2015, at 6:34 AM, NxtChg via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> >
> >> We should have the highest respect for what these people are doing, and
> we should try to do something constructive, not waste time with anger and
> disrespect.
> >
> > Why, exactly, should I have any respect for what these people are doing
> (and supposedly not have any respect for what the other side is doing)?
> >
> > From my point of view, the XT side _does_ something constructive. It's
> the Core side that resorts to dirty tactics and tries to sabotage
> community's free choice instead.
> >
> >
> >> Nobody should be forced to do anything.
> >
> > Great, so how about you go tell theymos to stop censoring XT posts and
> banning the other side on /r/Bitcoin?
> >
> > Let users decide what Bitcoin is or isn't.
> >
> >
> >> The developers are not telling you what to do, they are trying to do
> what they consider is best for the ecosystem given their technical
> abilities.
> >
> > The developers & Co are doing their best to stay in power, so they could
> continue imposing their will on Bitcoin ecosystem. This is the real power
> grab, not Gavin and Hearn, who merely provided an alternative.
> >
> > And the fear they show is most telling.
> >
> > _______________________________________________
> > 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: 7933 bytes --]

  reply	other threads:[~2015-08-17 14:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-16 22:34 [bitcoin-dev] Annoucing Not-BitcoinXT jyellen
2015-08-17  3:10 ` jl2012
2015-08-17  7:04 ` Peter Todd
2015-08-17 10:09 ` NxtChg
2015-08-17 12:40   ` Vali Zero
2015-08-17 13:34     ` NxtChg
2015-08-17 14:03       ` Eric Lombrozo
2015-08-17 14:09         ` Levin Keller [this message]
2015-08-17 14:30           ` Eric Lombrozo
2015-08-17 14:36         ` Adam Back
2015-08-17 14:58           ` GC
2015-08-17 15:03           ` Levin Keller
2015-08-17 15:07             ` Eric Lombrozo
2015-08-19  3:49           ` odinn
2015-08-17 15:10         ` NxtChg
2015-08-17 16:37       ` Eric Lombrozo
2015-08-17 16:55         ` Eric Lombrozo
2015-08-18  4:37           ` Dave Scotese
2015-08-18  5:13             ` GC
2015-08-18  5:33               ` Dave Scotese
2015-08-18  9:46         ` NxtChg
2015-08-19  9:47           ` Jorge Timón

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='CAG86ZOxWBMaBKzgRUp=Q5TvaT1v3OjNRFx2Xofd4FdLvpg9dGQ@mail.gmail.com' \
    --to=post@levinkeller.de \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=elombrozo@gmail.com \
    --cc=nxtchg@hush.com \
    /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