From: Bram Cohen <bram@bittorrent•com>
To: "t. khan" <teekhan42@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)
Date: Sat, 10 Dec 2016 15:12:25 -0800 [thread overview]
Message-ID: <CA+KqGkq6soxt-SK4Liby5NE=QSt4-OTZ-FfsEd6qDGwvZpnpKQ@mail.gmail.com> (raw)
In-Reply-To: <CAGCNRJqdu7DMC+AMR4mYKRAYStRMKVGqbnjtEfmzcoeMij5u=A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]
On Mon, Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Put another way: let’s stop thinking about what the max block size should
> be and start thinking about how full we want the average block to be
> regardless of size. Over the last year, we’ve had averages of 75% or
> higher, so aiming for 75% full seems reasonable, hence naming this concept
> ‘Block75’.
>
That's effectively making the blocksize limit completely uncapped and only
preventing spikes, and even in the case of spikes it doesn't differentiate
between 'real' traffic and low value spam attacks. It suffers from the same
fundamental problems as bitcoin unlimited: There are in the end no
transaction fees, and inevitably some miners will want to impose some cap
on block size for practical purposes, resulting in a fork.
Difficulty adjustment works because there's a clear goal of having a
certain rate of making new blocks. Without a target to attempt automatic
adjustment makes no sense.
[-- Attachment #2: Type: text/html, Size: 1442 bytes --]
next prev parent reply other threads:[~2016-12-10 23:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-05 15:27 t. khan
2016-12-10 10:44 ` s7r
2016-12-10 12:05 ` Hampus Sjöberg
2016-12-11 0:26 ` t. khan
2016-12-11 0:40 ` James Hilliard
2016-12-11 1:07 ` Bram Cohen
2016-12-11 17:11 ` s7r
2016-12-11 19:55 ` t. khan
2016-12-11 20:31 ` James Hilliard
2016-12-11 21:40 ` t. khan
2016-12-11 21:53 ` Bram Cohen
2016-12-11 21:55 ` James Hilliard
2016-12-11 22:30 ` t. khan
2016-12-11 20:38 ` Andrew Johnson
2016-12-11 23:22 ` s7r
2016-12-18 21:53 ` James MacWhyte
2016-12-19 1:42 ` Tom Harding
2016-12-10 23:12 ` Bram Cohen [this message]
2016-12-11 0:52 ` t. khan
[not found] <CAEgR2PEMPo3veqJat7OAps1DzTSNFJmJiRbkFgYKvYfxqdbUiw@mail.gmail.com>
[not found] ` <CAEgR2PELB1_s+o0Bj4Kj9vS27eoqP7gV_VS_6QHQtTUAOnMORg@mail.gmail.com>
[not found] ` <CAEgR2PFpGWxngq=fKGi7CC_d+=5YWzWwbEEsQNEifCuHAAPAHw@mail.gmail.com>
[not found] ` <CAEgR2PHnrsdaBiDgywvE9amK8_yPE_hBo0yYOYwUk4T8n7wnAQ@mail.gmail.com>
[not found] ` <CAEgR2PEgPkRe76hW0Jj7_Z1EdmmNTpTAOKGm_of2dG=XXUOtnA@mail.gmail.com>
[not found] ` <CAEgR2PHew+fcJWnAt+t8umcwKu4TkshH=AFJ-8MeYysud2MkBQ@mail.gmail.com>
[not found] ` <CAEgR2PEVwt_shiqwGjK6dPscRUTHayis0PaQO5Dj_fVEGGgaCQ@mail.gmail.com>
2016-12-10 12:23 ` Daniele Pinna
2016-12-10 17:39 ` Pieter Wuille
2016-12-11 3:17 ` Daniele Pinna
2016-12-11 5:29 ` Eric Voskuil
2016-12-11 9:21 ` Adam Back
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='CA+KqGkq6soxt-SK4Liby5NE=QSt4-OTZ-FfsEd6qDGwvZpnpKQ@mail.gmail.com' \
--to=bram@bittorrent$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=teekhan42@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