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 BB2AB9B for ; Thu, 13 Aug 2015 09:52:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3E147163 for ; Thu, 13 Aug 2015 09:52:38 +0000 (UTC) Received: by igfj19 with SMTP id j19so32335202igf.1 for ; Thu, 13 Aug 2015 02:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=N2OiN6moMkqlMIXBl4LIWGBfa5KJEqm4fEvRJ9U6VtY=; b=PQPugxPnia3qNmnd1yEK2aYa0z3nYjq/cPFTMNk1B48KBguLdzZiVm/Ww7KBj4SEab uNsqH+jAxz46i8lDGmGprUCt5bAFNxVdaULyb1VvZZfy/mBbTQI8uT+Taui8MwFFcxjh LrWw7fOzAmt6k3+1ruLd03LherQsoCOUB16UyZjP16XCdOVMgzwO05ZEk+Q1RZIQu/k5 61taRnxtpy+uuNew7iCwDlWR5nSMCbczolmTLzxKrktUb9NsK9TmKJi5YXLGkjkOurrH qnSlAmbTIkUhvvKnA52eUhOxJu+CStXTj/E23sK2Ip16n+UmG2vWaKJfUOjFtvb/OcUM KJ1w== MIME-Version: 1.0 X-Received: by 10.50.43.227 with SMTP id z3mr2105550igl.12.1439459557647; Thu, 13 Aug 2015 02:52:37 -0700 (PDT) Received: by 10.107.129.93 with HTTP; Thu, 13 Aug 2015 02:52:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Aug 2015 19:52:37 +1000 Message-ID: From: Ashley Holman To: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e0111c0169a2d45051d2e4be2 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 Subject: Re: [bitcoin-dev] A summary list of all concerns related to not rising the block size 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: Thu, 13 Aug 2015 09:52:38 -0000 --089e0111c0169a2d45051d2e4be2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A concern I have is about security (hash rate) as a function of block size. I am assuming that hash rate is correlated with revenue from mining. Total revenue from fees as a function of block size should be a curve. On one extreme of the curve, if blocks are too big, fee revenue tends towards 0 as there is no competition for block space. At the other extreme, if blocks are too small, fee revenue is limited only to what the most valuable use case(s) can afford. Somewhere in the middle there should be a sweet spot where fee revenue is maximised. It's not a static curve though, it should change as demand for block space changes. Failing to scale the block size as demand grows might be forfeiting potential miner revenue and hence security. (I don't think that should be a primary concern though since decentralisation should come first, but I'm just pointing it out as a secondary concern). On Wed, Aug 12, 2015 at 7:59 PM, Jorge Tim=C3=B3n < bitcoin-dev@lists.linuxfoundation.org> wrote: > I believe all concerns I've read can be classified in the following group= s: > > > 1) Potential indirect consequence of rising fees. > > - Lowest fee transactions (currently free transactions) will become > more unreliable. > - People will migrate to competing systems (PoW altcoins) with lower fees= . > > > 2) Software problem independent of a concrete block size that needs to > > be solved anyway, often specific to Bitcoin Core (ie other > > implementations, say libbitcoin may not necessarily share these > > problems). > > - Bitcoin Core's mempool is unbounded in size and can make the program > crash by using too much memory. > - There's no good way to increase the fee of a transaction that is > taking too long to be mined without the "double spending" transaction > with the higher fee being blocked by most nodes which follow Bitcoin > Core's default policy for conflicting spends replacements (aka "first > seen" replacement policy). > > I have started with the 3 concerns that I read more often, but please > suggest more concerns for these categories and suggest other > categories if you think there's more. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --089e0111c0169a2d45051d2e4be2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A concern I have is about security (hash rate) as a functi= on of block size.

I am assuming that hash rate is correl= ated with revenue from mining.

Total revenue from = fees as a function of block size should be a curve.=C2=A0 On one extreme of= the curve, if blocks are too big, fee revenue tends towards 0 as there is = no competition for block space.=C2=A0 At the other extreme, if blocks are t= oo small, fee revenue is limited only to what the most valuable use case(s)= can afford.=C2=A0 Somewhere in the middle there should be a sweet spot whe= re fee revenue is maximised.=C2=A0 It's not a static curve though, it s= hould change as demand for block space changes.

Fa= iling to scale the block size as demand grows might be forfeiting potential= miner revenue and hence security.

(I don't th= ink that should be a primary concern though since decentralisation should c= ome first, but I'm just pointing it out as a secondary concern).
<= /div>

On Wed, Aug = 12, 2015 at 7:59 PM, Jorge Tim=C3=B3n <bitcoin-dev@lis= ts.linuxfoundation.org> wrote:
I believe all concerns I've read can be classified in the following= groups:

> 1) Potential indirect consequence of rising fees.

- Lowest fee transactions (currently free transactions) will become
more unreliable.
- People will migrate to competing systems (PoW altcoins) with lower fees.<= br>
> 2) Software problem independent of a concrete block size that needs to=
> be solved anyway, often specific to Bitcoin Core (ie other
> implementations, say libbitcoin may not necessarily share these
> problems).

- Bitcoin Core's mempool is unbounded in size and can make the program<= br> crash by using too much memory.
- There's no good way to increase the fee of a transaction that is
taking too long to be mined without the "double spending" transac= tion
with the higher fee being blocked by most nodes which follow Bitcoin
Core's default policy for conflicting spends replacements (aka "fi= rst
seen" replacement policy).

I have started with the 3 concerns that I read more often, but please
suggest more concerns for these categories and suggest other
categories if you think there's more.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--089e0111c0169a2d45051d2e4be2--