From: Mark Friedenbach <mark@friedenbach•org>
To: Levin Keller <post@levinkeller•de>
Cc: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Minimum Block Size
Date: Sun, 16 Aug 2015 09:52:32 -0700 [thread overview]
Message-ID: <CAOG=w-sEqBpNK3ncJhKVp7h3+HckeFF0WhdDtjh=t6NH+Ok8Nw@mail.gmail.com> (raw)
In-Reply-To: <CAG86ZOzEnjMw4xam5oUuuvyfoAps=47j418cZcw9BLs-yUCB2g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1924 bytes --]
Levin, it is a complicated issue for which there isn't an easy answer. Part
of the issue is that "block size" doesn't actually measure resource usage
very reliably. It is possible to support a much higher volume of typical
usage transactions than transactions specifically constructed to cause DoS
issues. But if "block size" is the knob being tweaked, then you must design
for the DoS worst case, not the average/expected use case.
Additionally, there is an issue of time horizons and what presumed
improvements are made to the client. Bitcoin Core today can barely handle
1MB blocks, but that's an engineering limitation. So are we assuming fixes
that aren't actually deployed yet? Should we raise the block size before
that work is tested and its performance characteristics validated?
It's a complicated issue without easy answers, and that's why you're not
seeing straightforward statements of "2MB", "8MB", or "20MB" from most of
the developers.
But that's not to say that people aren't doing anything. There is a
workshop being organized for September 12-13th that will cover much of
these "it's complicated" issues. There will be a follow-on workshop in the
Nov/Dec timeframe in which specific proposals will be discussed. I
encourage you to participate:
http://scalingbitcoin.org/
On Sun, Aug 16, 2015 at 9:41 AM, Levin Keller via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hey everyone,
>
> as with the current "max block size" debate I was wondering: Is anyone
> here in favor of a minimum block size (say 2 MB or so)? If so I would be
> interested in an exchange (maybe off-list) of ideas. I am in favor of a
> lower limit and am giving it quite a bit of thought at the moment.
>
> Cheers
>
> Levin
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 2775 bytes --]
next prev parent reply other threads:[~2015-08-16 16:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-16 16:41 Levin Keller
2015-08-16 16:52 ` Mark Friedenbach [this message]
2015-08-17 0:30 ` Jeff Garzik
2015-08-17 1:20 ` Patrick Strateman
2015-08-17 16:18 ` 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='CAOG=w-sEqBpNK3ncJhKVp7h3+HckeFF0WhdDtjh=t6NH+Ok8Nw@mail.gmail.com' \
--to=mark@friedenbach$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=post@levinkeller$(echo .)de \
/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