From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D8C8F6C for ; Mon, 2 Jan 2017 19:32:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com [209.85.217.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 29D11192 for ; Mon, 2 Jan 2017 19:32:26 +0000 (UTC) Received: by mail-ua0-f179.google.com with SMTP id 34so267653978uac.1 for ; Mon, 02 Jan 2017 11:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ani6j/nDXFwO+cTjEk6nDIdW2dusNrOqJlKsx2R8FVA=; b=bgYiKPfIFrw96zz8OQ4SdKNiMqmuwAnyWSuiGy3cR3cDptfJSBWC6zdZVncuO11tHV doM0WYPQh4tChbbYIw0mLUFyXxmBqNnX3Qs73PiwmhdtelFjuU6ZGK//PHW9/QGQGfzz aJ48elKUTyb5sM39GKSSgxFQ83f8WWt080Xz5/kxkXhoPEdPEqRAn7NapVSohcSmp0cj Antw70Grgj267QAo/PlB8WCCtL/6SftDWOZZCIdWHxn7Thl+MgW5ZaB1mLiH9shsWW6B s1GUHKowu36nxXgOm8uJjgA+AtgdWNPbme02IC/+pF177fYuWEyYi+iS7m5PQWYrD5lw aQhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ani6j/nDXFwO+cTjEk6nDIdW2dusNrOqJlKsx2R8FVA=; b=XsVZBQgm3ANBlG7x5VjiE4aP1E7D1jGy7pEzklhuLGLrjDQYlduzHm2h5CD1hl5Tpm DSPuKpIZNWq+ZtsxbgDiqD9w6dTrzvqPTAXJae5XasEJUk02brmDb5UoZIKcQ7lcyeVK 1oj39fUI9hY1VXv5PReqdEAtvwVhN5BHevIOhhGbq1MXpntB+mCR+3F2VHtpZMAq7Cvt jGtO4UpU6izdPPOUEKiSmgO1+D5ObXubZLrrL6HsYpuCyHK73xErxFBlFnpEQVXAXqB2 JviKp2S0UrEN/G+cMvYY4nW71spJkABvCR+PZLodh576iZljM63wliPhtu4nychGwGJ7 yZHg== X-Gm-Message-State: AIkVDXKAzhgp5kkrbhj0Td+WK7YT3sUBa4lcT+IXPJLkIZ+4M7lryiXLKihiaJKHc6XL9iuDPYaUXNvThvWm7w== X-Received: by 10.176.7.215 with SMTP id d23mr45634948uaf.112.1483385545365; Mon, 02 Jan 2017 11:32:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.49.144 with HTTP; Mon, 2 Jan 2017 11:32:24 -0800 (PST) In-Reply-To: <2273244.fZU5ULDz4l@cherry> References: <2273244.fZU5ULDz4l@cherry> From: "t. khan" Date: Mon, 2 Jan 2017 14:32:24 -0500 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=f403045f8ab47f1d270545219c4b X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP - 'Block75' - New algorithm X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 19:32:27 -0000 --f403045f8ab47f1d270545219c4b Content-Type: text/plain; charset=UTF-8 Math should decide the max block size, not humans (miners in this case). The goal of Block75 is to manage the max block size without any human intervention. Under Block75, miners don't have any direct control but could still choose to mine smaller blocks (same as now), though doing so would cost them the fees from transactions they didn't include in their blocks. A maximum block size is necessary to prevent a single nefarious miner from creating a ridiculously large block which would break the network. - t.k. On Mon, Jan 2, 2017 at 2:01 PM, Tom Zander wrote: > On Monday, 2 January 2017 13:04:37 CET t. khan via bitcoin-dev wrote: > > Thoughts? > > This proposal doesn't change the block size, it only changes the maximum > block size. Which is expected, nothing bad there. > > The direct consequence of this, though is that the miners set the maximum > block size. Because they decide on the actual created block size. > > This leads me to the simple question why we can't just give the miners full > control of the maximum block size directly? > > The fact of the matter is that miners have for the full history of Bitcoin > been able to set the block size, until they hit the 1MB limit. > And your proposal keeps that property, but why have a maximum in the > protocol? > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > --f403045f8ab47f1d270545219c4b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Math should decide the max block size, not humans (miners = in this case).=C2=A0The goal of Block75 is to manage the max block size wit= hout any human intervention.

Under Block75, miners don&#= 39;t have any direct control but could still choose to mine smaller blocks = (same as now), though doing so would cost them the fees from transactions t= hey didn't include in their blocks.

A max= imum block size is necessary to prevent a single nefarious miner from creat= ing a ridiculously large block which would break the network.
- t.k.

On Mon, Jan 2, 2017 at 2:01 PM, Tom Zander <= tomz@freedommail.c= h> wrote:
On Monday, 2 January 2017 13:04= :37 CET t. khan via bitcoin-dev wrote:
> Thoughts?

This proposal doesn't change the block size, it only changes the maximu= m
block size. Which is expected, nothing bad there.

The direct consequence of this, though is that the miners set the maximum block size. Because they decide on the actual created block size.

This leads me to the simple question why we can't just give the miners = full
control of the maximum block size directly?

The fact of the matter is that miners have for the full history of Bitcoin<= br> been able to set the block size, until they hit the 1MB limit.
And your proposal keeps that property, but why have a maximum in the
protocol?
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel<= /a>

--f403045f8ab47f1d270545219c4b--