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 70A34BC8 for ; Sat, 27 Jun 2015 17:46:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B4C9CA8 for ; Sat, 27 Jun 2015 17:46:55 +0000 (UTC) Received: by oigb199 with SMTP id b199so94599898oig.3 for ; Sat, 27 Jun 2015 10:46:55 -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=x1AnuYnypMRWICGwxu6qEwKnn6hfw67dlfqopQKSXjk=; b=AnPcWoxh7px6oY2JUFugIzvwoN9Vf+Jq2eozc4AayKMoJe85zgrm+sVzAhReWxlzyP aAfJqBwOKUMnGMBCGrUdD6tNQkdjYMBof95pAq9Z7lzNa8GS7/JiZQ99Lw+WZ4Rtf9Zu RYAqq5yeNUr4boSubmkigA9RXwVyF8b27YuIMJ86NsjTPykRPOYo0H1Cfd3lADYZJjRR /2MIyBoNXkrooHDJseLpq2vxs9/XKJobVATxwof0eO9ZbN/55M7WXUnOJeis6vUOAE0S 29Z5lijKv3tWkJ1adhJYP5tP1ElxFlM9Bj4sC+kEdBj/FARZm+r3dBBTOB2a1Wni7z6J HHUw== MIME-Version: 1.0 X-Received: by 10.60.155.97 with SMTP id vv1mr6953160oeb.15.1435427215180; Sat, 27 Jun 2015 10:46:55 -0700 (PDT) Received: by 10.202.87.197 with HTTP; Sat, 27 Jun 2015 10:46:55 -0700 (PDT) In-Reply-To: <20150627173724.GA30546@muck> References: <1EF70EBC-8BB8-4A93-8591-52B2B0335F6C@petertodd.org> <20150627172011.GB18729@muck> <20150627173724.GA30546@muck> Date: Sat, 27 Jun 2015 19:46:55 +0200 Message-ID: From: Benjamin To: Peter Todd Content-Type: multipart/alternative; boundary=047d7bd6c512430986051983717d 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] A Proposed Compromise to the Block Size Limit 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 17:46:56 -0000 --047d7bd6c512430986051983717d Content-Type: text/plain; charset=UTF-8 There is no ensured Quality of service, is there? If you "bid" higher, then you don't know what you are going to get. Also because you have no way of knowing what *others* are bidding. Only if you have auctions (increasing increments) you can establish a feedback loop to settle demand and supply. And the supply side doesn't adapt. Adapting supply would help resolve parts of the capacity problem. On Sat, Jun 27, 2015 at 7:37 PM, Peter Todd wrote: > On Sat, Jun 27, 2015 at 07:26:00PM +0200, Benjamin wrote: > > "Thus we have a fixed capacity system where access is mediated by supply > > and demand transaction fees." > > > > There is no supply and demand. That would mean users would be able to > adapt > > fees and get different quality of service depending on current capacity. > > For example if peak load is 10x average load, then at those times fees > > would be higher and users would delay transactions to smooth out demand. > > That's exactly how Bitcoin works already. See my article on how > transaction fees work for more details: > > https://gist.github.com/petertodd/8e87c782bdf342ef18fb > > -- > 'peter'[:-1]@petertodd.org > 0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24 > --047d7bd6c512430986051983717d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is no ensured Quality of service, is there? If you &= quot;bid" higher, then you don't know what you are going to get. A= lso because you have no way of knowing what others=C2=A0are bidding.= Only if you have auctions (increasing increments) you can establish a feed= back loop to settle demand and supply. And the supply side doesn't adap= t. Adapting supply would help resolve parts of the capacity problem.
<= div class=3D"gmail_extra">
On Sat, Jun 27, 20= 15 at 7:37 PM, Peter Todd <pete@petertodd.org> wrote:
On Sat, Jun 27, 2015 at 07:26= :00PM +0200, Benjamin wrote:
> "Thus we have a fixed capacity system where access is mediated by= supply
> and demand transaction fees."
>
> There is no supply and demand. That would mean users would be able to = adapt
> fees and get different quality of service depending on current capacit= y.
> For example if peak load is 10x average load, then at those times fees=
> would be higher and users would delay transactions to smooth out deman= d.

That's exactly how Bitcoin works already. See my article on how<= br> transaction fees work for more details:

https://gist.github.com/petertodd/8e87c782bdf3= 42ef18fb

--
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24

--047d7bd6c512430986051983717d--