Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2BB41ABF for ; Sat, 27 Jun 2015 06:13:14 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from laozi.macaubase.com (z83l79.static.ctm.net [202.175.83.79]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id EC9B1179 for ; Sat, 27 Jun 2015 06:13:12 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by laozi.macaubase.com (Postfix) with ESMTP id 93E867D41AE for ; Sat, 27 Jun 2015 14:13:10 +0800 (HKT) X-Virus-Scanned: amavisd-new at macaubase.com Received: from laozi.macaubase.com ([127.0.0.1]) by localhost (laozi.macaubase.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElMlRIcaOuV2 for ; Sat, 27 Jun 2015 14:13:10 +0800 (HKT) Received: from dmac13-2.local (nz168l31.bb18094.ctm.net [180.94.168.31]) by laozi.macaubase.com (Postfix) with ESMTPSA id 8090F7C41EC for ; Sat, 27 Jun 2015 14:13:09 +0800 (HKT) Message-ID: <558E3EFD.9040602@ktorn.com> Date: Sat, 27 Jun 2015 14:13:17 +0800 From: Filipe Farinha User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: bitcoin-dev@lists.linuxfoundation.org References: <558DA56F.3010703@jrn.me.uk> <20150626193630.GB17829@muck> In-Reply-To: <20150626193630.GB17829@muck> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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] The need for larger blocks 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: Sat, 27 Jun 2015 06:13:14 -0000 On 27/06/2015 03:36, Peter Todd wrote: > * Make websites with easy to understand displays of what the current mempool > backlog is, and what fee/KB is needed to get to the front of the queue. We've > done a great job for Bitcoin price charts, let's extend that to transaction > fees. > +1 This is especially important if take into account all the projects that aim to build upon the bitcoin blockchain and that can have a significant impact, both in terms of storage space as well as transaction volume spikes. Just recently I suggested the need for a BIP to standardize reporting of "delay alerts" in wallets, so that users can act accordingly (i.e. fee-bump, postpone, cancel) before sending their transactions during these periods of increased transaction volume. https://community.blockstack.org/t/blockstore-footprint-on-blockchain/68/5?u=ktorn IMHO keeping the users informed of potential issues before committing transactions to the network can go a long way towards preventing frustration and potential backlashes against blockchain tech. Filipe Farinha