From: "Jérôme Legoupil" <jjlegoupil@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
Date: Mon, 1 Jun 2015 14:45:21 +0200 [thread overview]
Message-ID: <CAFnMCfd8N_2nvspXF+Tro_SsofUUrMy4_QG9tRbPm1pUWtUCXQ@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]
>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
[-- Attachment #2: Type: text/html, Size: 2765 bytes --]
next reply other threads:[~2015-06-01 12:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-01 12:45 Jérôme Legoupil [this message]
2015-06-01 13:00 ` Adam Back
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=CAFnMCfd8N_2nvspXF+Tro_SsofUUrMy4_QG9tRbPm1pUWtUCXQ@mail.gmail.com \
--to=jjlegoupil@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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