Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 11DC5ABF for ; Sat, 27 Jun 2015 07:14:43 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com [209.85.220.182]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 419C7E7 for ; Sat, 27 Jun 2015 07:14:42 +0000 (UTC) Received: by qkbp125 with SMTP id p125so66807302qkb.2 for ; Sat, 27 Jun 2015 00:14:41 -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 :cc:content-type; bh=hR/S4+YQYNCxzY5iABTVCpgnDmIw8PT5EdEE7IoyaPE=; b=fTGBdwmA4oOePDVpTQXazRlvpn02K41FCuMjYrR1KFrIue//cYlaZAx05EGitK5cAm XSKdrE1wemEhEOeuiWtRxFjnAZ4mQNclQr9194jFYJEnoZNiZujirxauVkI++No9e2Rs 5orcNeOY9yh57p67kj0YTDrU6hEbIbI1RQZNT63VJYPWrqKN8uWW0F/NnDLsYBWFbaKv ZwQwu8obegpWG5BsYIZDQs+f8ylOl6tee8LPAPS3aObAf4QtCat90JX5AjHfczwaZC46 lILMjWo+hgow4LKX6H/N5/aXrxzJtvGQfDoUa/RFrD2zvpa/ouePlwGlJZz0gJ387zd5 vkIw== MIME-Version: 1.0 X-Received: by 10.55.33.215 with SMTP id f84mr11900021qki.60.1435389281529; Sat, 27 Jun 2015 00:14:41 -0700 (PDT) Received: by 10.140.91.37 with HTTP; Sat, 27 Jun 2015 00:14:41 -0700 (PDT) In-Reply-To: <558E3EFD.9040602@ktorn.com> References: <558DA56F.3010703@jrn.me.uk> <20150626193630.GB17829@muck> <558E3EFD.9040602@ktorn.com> Date: Sat, 27 Jun 2015 00:14:41 -0700 Message-ID: From: Aaron Voisine To: Filipe Farinha Content-Type: multipart/alternative; boundary=001a1144d2fa3d762505197a9cef 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 Cc: bitcoin-dev@lists.linuxfoundation.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 07:14:43 -0000 --001a1144d2fa3d762505197a9cef Content-Type: text/plain; charset=UTF-8 Also remember that the sender is not the one who cares about delays or even getting confirmations at all, it's the receiver who's concerned with these things. They have to tell the sender up-front what they're willing to accept in exchange for goods and services. Aaron Voisine co-founder and CEO breadwallet.com On Fri, Jun 26, 2015 at 11:13 PM, Filipe Farinha wrote: > 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 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a1144d2fa3d762505197a9cef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Also remember that the sender is not the one who cares abo= ut delays or even getting confirmations at all, it's the receiver who&#= 39;s concerned with these things. They have to tell the sender up-front wha= t they're willing to accept in exchange for goods and services.


Aaron Voisine
co-founder and CEO
breadwallet.com

On Fri, Jun 26, 2015 at 11:13 PM, Filipe Far= inha <filipe@ktorn.com> wrote:
On 27/06/2015 03:36, Peter Todd wrote:
* Make websites with easy to understand displays of what the current mempoo= l
=C2=A0 =C2=A0backlog is, and what fee/KB is needed to get to the front of t= he queue. We've
=C2=A0 =C2=A0done a great job for Bitcoin price charts, let's extend th= at to transaction
=C2=A0 =C2=A0fees.

 +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 impac= t, 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 &q= uot;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://communit= y.blockstack.org/t/blockstore-footprint-on-blockchain/68/5?u=3Dktorn
IMHO keeping the users informed of potential issues before committing trans= actions to the network can go a long way towards preventing frustration and= potential backlashes against blockchain tech.

Filipe Farinha

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

--001a1144d2fa3d762505197a9cef--