public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace.org>
To: "Jérôme Legoupil" <jjlegoupil@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
Date: Mon, 1 Jun 2015 14:00:49 +0100	[thread overview]
Message-ID: <CALqxMTFJD5HrPjt=Ua5yFti9R_rj1gpFGGOKQb__xj8Bb4epGQ@mail.gmail.com> (raw)
In-Reply-To: <CAFnMCfd8N_2nvspXF+Tro_SsofUUrMy4_QG9tRbPm1pUWtUCXQ@mail.gmail.com>

Agree with everything you said.  Spot on observations on all counts.
Thank you for speaking up.

Adam

On 1 June 2015 at 13:45, Jérôme Legoupil <jjlegoupil@gmail.com> wrote:
>>What do other people think?
>>
>>
>>If we can't come to an agreement soon, then I'll ask for help
>>reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
>>big increase now that grows over time so we may never have to go through
>>all this rancor and debate again."
>>
>>
>>I'll then ask for help lobbying the merchant services and exchanges and
>>hosted wallet companies and other bitcoind-using-infrastructure companies
>
>
> It's surprising to see a core dev going to the public to defend a proposal
> most other core devs disagree on, and then lobbying the Bitcoin ecosystem.
>
> This is an very unhealthy way to go because it incentives the other core
> devs to stop their technical work and go public and lobby too (cf G.Maxwell
> trying to raise redditters awareness).
>
> We need core devs to work on technical issues, not waste time doing
> politics, but Gavin's confrontational approach doesn't give them much of a
> choice.
>
> I fear that because of this approach, in the next monthes, core devs with be
> lobbying and doing politics : precious time will be wasted for everyone
> having stake in Bitcoin.
>
>
> Regarding the 20MB proposal content:
>
> Decentralization is the core of Bitcoin's security model and thus that's
> what gives Bitcoin its value.
>
> The danger is that decentralization tends naturally towards centralization,
> because centralization is more efficient. Going from decentralization to
> centralization is easy, going the other way is a lot harder :
> decentralization we lose, may never be gained back.
>
> Regarding "the urgency to do something":
>
> I believe it would be extremely healthy for the network to bump into any
> limit ASAP ... (let it be 1MB) : to incentive layer 2 and offchain solutions
> to scale Bitcoin : there are promising designs/solutions out there (LN,
> ChainDB, OtherCoin protocole, ...), but most don't get much attention,
> because there is right now no need for them. And, I am sure new solutions
> will be invented.
>
> If during the "1MB bumpy period" something goes wrong, consensus among the
> community would be reached easily if necessary.
>
> Pretending there is urgency and that Apocalypse is approaching is a fallacy.
>
> The Gavin 20MB proposal is compromising Bitcoin's long-term security in an
> irreversible way, for gaining short-term better user experience.
>
> I oppose the Gavin proposal in both content and form.
>
> Cheers,
> Jerome
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



  reply	other threads:[~2015-06-01 13:00 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-01 12:45 [Bitcoin-development] Proposed alternatives to the 20MB step Jérôme Legoupil
2015-06-01 13:00 ` Adam Back [this message]
2015-06-01 13:37 ` Gavin Andresen
2015-06-01 15:55 ` Mike Hearn
2015-06-01 16:41   ` Jameson Lopp
2015-06-02  0:09   ` Eric Voskuil
2015-06-02 11:03     ` Mike Hearn
2015-06-02 16:18       ` Eric Voskuil
2015-06-13  6:05       ` odinn

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='CALqxMTFJD5HrPjt=Ua5yFti9R_rj1gpFGGOKQb__xj8Bb4epGQ@mail.gmail.com' \
    --to=adam@cypherspace.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jjlegoupil@gmail.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