From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yqr1d-0003uF-M9 for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 22:45:45 +0000 X-ACL-Warn: Received: from mail-ig0-f170.google.com ([209.85.213.170]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yqr1c-00045t-LY for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 22:45:45 +0000 Received: by igbsb11 with SMTP id sb11so33535271igb.0 for ; Fri, 08 May 2015 15:45:39 -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:from:date :message-id:subject:to:cc:content-type; bh=xp7NZ2wCo3pepInmtij1/SV/WKBHuwkC0e+FDGjriYk=; b=THWvd1OJjWMQV5sKjr3DtByRMKSw2Tqa8J6H7MfWaJG/dJbFn5XzlN1hZd8UC2VFo6 9isJwyJxZAKt3NcDM1h2YAbTANYa0D4jGxy2bm0LE3BTJhYkSom6kIhY1xo9g4qNtmc0 44ytqYeHQdQTdILrNKPppcMHeQ8ZlqyINZ6jvUKDBbIujAsCCZEOxVyTqr4V7CZvcB9q rpEKlpprti6O/gjiDlhMTTgqUmBMU7dBFYHq/YES1BRMsatAmwteE2nbuK2XxXhNVTci 3AaWKT40nTJrmAu9LqRjVX1rFzrNsZrVrDAbJJ7dZEhzxZlx8ssWlBfIMSTlUuF6b0g0 4R6g== X-Gm-Message-State: ALoCoQmE46tj7SBkrx3Ut04cZHAWf8XosDK3nb1uV1zDXD5Fql90K2OhwGvyYcLvEPfDKMxGVKnI X-Received: by 10.50.21.1 with SMTP id r1mr1780455ige.46.1431125139370; Fri, 08 May 2015 15:45:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.25.203 with HTTP; Fri, 8 May 2015 15:45:19 -0700 (PDT) X-Originating-IP: [173.228.107.141] In-Reply-To: References: <16096345.A1MpJQQkRW@crushinator> From: Mark Friedenbach Date: Fri, 8 May 2015 15:45:19 -0700 Message-ID: To: Aaron Voisine Content-Type: multipart/alternative; boundary=047d7b6d8f948fc9f1051599c970 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Yqr1c-00045t-LY Cc: Bitcoin Development Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step function X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 22:45:45 -0000 --047d7b6d8f948fc9f1051599c970 Content-Type: text/plain; charset=UTF-8 On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine wrote: > This is a clever way to tie block size to fees. > > I would just like to point out though that it still fundamentally is using > hard block size limits to enforce scarcity. Transactions with below market > fees will hang in limbo for days and fail, instead of failing immediately > by not propagating, or seeing degraded, long confirmation times followed by > eventual success. > There are already solutions to this which are waiting to be deployed as default policy to bitcoind, and need to be implemented in other clients: replace-by-fee and child-pays-for-parent. --047d7b6d8f948fc9f1051599c970 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine <voisine@gm= ail.com> wrote:
This is a cleve= r way to tie block size to fees.

I would just like to po= int out though that it still fundamentally is using hard block size limits = to enforce scarcity. Transactions with below market fees will hang in limbo= for days and fail, instead of failing immediately by not propagating, or s= eeing degraded, long confirmation times followed by eventual success.
=

There are already solutions to this = which are waiting to be deployed as default policy to bitcoind, and need to= be implemented in other clients: replace-by-fee and child-pays-for-parent.=
--047d7b6d8f948fc9f1051599c970--