From: Gavin Andresen <gavinandresen@gmail•com>
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 09:37:11 -0400 [thread overview]
Message-ID: <CABsx9T2D_yde6ZCH0tib6kxBfOgf-3BZDcEx4zsiqrTsA=Nvzw@mail.gmail.com> (raw)
In-Reply-To: <CAFnMCfd8N_2nvspXF+Tro_SsofUUrMy4_QG9tRbPm1pUWtUCXQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3945 bytes --]
RE: going to the public:
I started pushing privately for SOMETHING, ANYTHING to be done, or at the
very least for there to be some coherent plan besides "wait and see" back
in February.
As for it being unhealthy for me to write the code that I think should be
written and asking people to run it:
Ok. What would you suggest I do? I believe scaling up is the number one
priority right now. I think core devs SHOULD be taking time to solve it,
because I think the uncertainty of how it will be solved (or if it will be
solved) is bad for Bitcoin.
I think working on things like fixing transaction malleability is great...
but the reason to work on that is to enable smart contracts and all sorts
of other interesting new uses of the blockchain. But if we're stuck with
1MB blocks then there won't be room for all of those interesting new uses
on the blockchain.
Others disagree, and have the advantage of status-quo : if nothing is done,
they get what they want.
Based on some comments I've seen, I think there is also concern that "my
own personal network/computer connection might not be able to handle more
transaction volume." That is NOT a good reason to limit scalability, but I
think it is clouding the judgement of many of the core contributors who
started contributing as a spare-time hobby from their homes (where maybe
they have crappy DSL connections).
RE: decentralization:
I think this is a red-herring. I'll quote something I said on reddit
yesterday:
"I don't believe a 20MB max size will increase centralization to any
significant degree.
See
http://gavinandresen.ninja/does-more-transactions-necessarily-mean-more-centralized
and http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
And I think we will have a lot LESS centralization of payments via services
like Coinbase (or hubs in some future StrawPay/Lightning network) if the
bitcoin network can directly handle more payment volume.
The centralization trade-offs seems very clear to me, and I think the "big
blocks mean more centralized" arguments are either just wrong or are
exaggerated or ignore the tradeoff with payment centralization (I think
that is a lot more important for privacy and censorship resistance)."
RE: incentives for off-chain solutions:
I'll quote myself again from
http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea :
"The “layer 2” services that are being built on top of the blockchain are
absolutely necessary to get nearly instant real-time payments,
micropayments and high volume machine-to-machine payments, to pick just
three examples. The ten-minute settlement time of blocks on the network is
not fast enough for those problems, and it will be the ten minute block
interval that drives development of those off-chain innovations more than
the total number of transactions supported."
On Mon, Jun 1, 2015 at 8:45 AM, Jérôme Legoupil <jjlegoupil@gmail•com>
wrote:
> If during the "1MB bumpy period" something goes wrong, consensus among the
> community would be reached easily if necessary.
>
That is the problem: this will be a "frog in boiling water" problem. I
believe there will be no sudden crisis-- instead, transactions will just
get increasingly unreliable and expensive, driving more and more people
away from Bitcoin towards... I don't know what. Some less expensive, more
reliable, probably more-centralized solution.
The Gavin 20MB proposal is compromising Bitcoin's long-term security in an
> irreversible way, for gaining short-term better user experience.
>
If by long-term security you mean "will transaction fees be high enough to
pay for enough hashing power to secure the network if there are bigger
blocks" I've written about that:
http://gavinandresen.ninja/block-size-and-miner-fees-again
If you mean something else, then please be specific.
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 5383 bytes --]
next prev parent reply other threads:[~2015-06-01 13:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-01 12:45 Jérôme Legoupil
2015-06-01 13:00 ` Adam Back
2015-06-01 13:37 ` Gavin Andresen [this message]
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='CABsx9T2D_yde6ZCH0tib6kxBfOgf-3BZDcEx4zsiqrTsA=Nvzw@mail.gmail.com' \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jjlegoupil@gmail$(echo .)com \
/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