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 68DA1AE7 for ; Wed, 24 Jun 2015 02:15:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9AC28F4 for ; Wed, 24 Jun 2015 02:15:56 +0000 (UTC) Received: by igin14 with SMTP id n14so24848639igi.1 for ; Tue, 23 Jun 2015 19:15:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fhMWAv9yFTBqd/YuaRnKyxvxKdhLXCBlA9qoQEQfps8=; b=DTnUPNmjL2suXKuNs4hr6GrhUCK5NIu12bZ8rY5M9WG4Zs8vKoeb9cL2m8gjfqKT5i 6opN27/FaaXsLhJOdNvawcZftzs39yU+Ga4J9pnDgk8ikS7Duz1YLIsnkWHUyAXmfQQk D8N3xS75zoHx1q0+UAl85uLTfm5o3eP+8+I3ysXgD5lpaY+noNUfCLQPRDpTOui2sCYP tcfsfhldrS0vPmsNtGgp3MHJvBpEEUwYL9PUAugnVpTcpTxiCMxQY5XvT+6lLF4g+lFo iQ3SEG4Qi9MmH0kAoxpQdUuSHe5C3KPJgAhgHpPXxkaGlkvjDNI2nPIKzMdu8MbkjAOd xSyQ== X-Gm-Message-State: ALoCoQlsNClx57xgpOBDKWzQ9bZBr98iVixFmW5KJ50eNxSUhEG5EXFCA4AUtw1DqI58HSOACBRF MIME-Version: 1.0 X-Received: by 10.107.3.227 with SMTP id e96mr14933907ioi.50.1435112156146; Tue, 23 Jun 2015 19:15:56 -0700 (PDT) Received: by 10.107.149.20 with HTTP; Tue, 23 Jun 2015 19:15:55 -0700 (PDT) X-Originating-IP: [172.56.16.75] Received: by 10.107.149.20 with HTTP; Tue, 23 Jun 2015 19:15:55 -0700 (PDT) In-Reply-To: <558A0FCB.2040908@ktorn.com> References: <558A0FCB.2040908@ktorn.com> Date: Tue, 23 Jun 2015 19:15:55 -0700 Message-ID: From: Mark Friedenbach To: Filipe Farinha Content-Type: multipart/alternative; boundary=001a113f0c5a48012905193a1618 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Mempool size consensus + dynamic block size re-targetting X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 02:15:57 -0000 --001a113f0c5a48012905193a1618 Content-Type: text/plain; charset=UTF-8 Anyone could lie. On Jun 23, 2015 7:12 PM, "Filipe Farinha" wrote: > To my knowledge so far the main proposals regarding block size changes are > either based on predictions, which traditionally we're not very good at, or > a voting mechanism by a limited set of stakeholders (miners) whose > interests may not be aligned with the rest of the community. > > Neither strategy takes into account the most important factor: real-time > changes to the mempool. This is for a valid reason, there is currently no > consensus on the size of the mempool. > > So my question is: has anyone considered the pros and cons of creating > consensus around the current (approximate) mempool size? > > I propose that, at the expense of some transaction overhead (3 or 4 extra > bytes?), each full-node that broadcasts a new transaction can add a > mempool_size field that represents their current view of the mempool. As > blocks are mined with this new data (which may or not be aggregated in the > block header), all nodes can quickly reach consensus on the current > average/median/etc mempool size, and agree on a suitable periodic blocksize > "re-targetting" (similarly to mining difficulty). > > Since all full-nodes (not just miners) get to vote with their transactions > the consensus is truly global, and we don't have to change blocksize > blindly in anticipation of an unpredictable future. > > Would this not work, and if not, why? > > Filipe Farinha > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a113f0c5a48012905193a1618 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Anyone could lie.

On Jun 23, 2015 7:12 PM, "Filipe Farinha&qu= ot; <filipe@ktorn.com> wrote:=
To my knowledge so = far the main proposals regarding block size changes are either based on pre= dictions, which traditionally we're not very good at, or a voting mecha= nism by a limited set of stakeholders (miners) whose interests may not be a= ligned with the rest of the community.

Neither strategy takes into account the most important factor: real-time ch= anges to the mempool. This is for a valid reason, there is currently no con= sensus on the size of the mempool.

So my question is: has anyone considered the pros and cons of creating cons= ensus around the current (approximate) mempool size?

I propose that, at the expense of some transaction overhead (3 or 4 extra b= ytes?), each full-node that broadcasts a new transaction can add a mempool_= size field that represents their current view of the mempool. As blocks are= mined with this new data (which may or not be aggregated in the block head= er), all nodes can quickly reach consensus on the current average/median/et= c mempool size, and agree on a suitable periodic blocksize "re-targett= ing" (similarly to mining difficulty).

Since all full-nodes (not just miners) get to vote with their transactions = the consensus is truly global, and we don't have to change blocksize bl= indly in anticipation of an unpredictable future.

Would this not work, and if not, why?

Filipe Farinha
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--001a113f0c5a48012905193a1618--