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 E275CAB2 for ; Sat, 27 Jun 2015 19:34:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5D55D1FB for ; Sat, 27 Jun 2015 19:34:17 +0000 (UTC) Received: by obctg8 with SMTP id tg8so84446840obc.3 for ; Sat, 27 Jun 2015 12:34:16 -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=jY2uY1DPLLyJDAz8IKPhJywYAb6SMEO3XySMSHBEjFQ=; b=SQUnbQUEliqt+qrddRV8VVboCedTmrH8HlqgdSXNGmXZ9EPOg7Ky+WpZ7pbnKMJCaJ DGHx2J52EkruI3zUeDuZC7jUmTbzNyiqqfOKn1TZvrbdlV997JqDHHakseKVgDrsqwLr zOuS93dV4n7LT+ZJcDNjvv+o/RfKUQT2//urfLGbzUS6c5ROE247yPNPbJMefsZbyy+4 /p5KOCq+GQ31hYu2iqZliawKEnIrNfkQJj2OVbuIVSxUjBWCjydh1z4D+Pfvk2tNbuRm h3ZXVVGkG+Q4bO7T9ZdiZTvrFdxRJXKYwdqq2vvhzUMe9CaSL1cpRyL7X8Bfu6n977EV 8Inw== MIME-Version: 1.0 X-Received: by 10.202.73.198 with SMTP id w189mr6677571oia.102.1435433656819; Sat, 27 Jun 2015 12:34:16 -0700 (PDT) Received: by 10.202.87.197 with HTTP; Sat, 27 Jun 2015 12:34:16 -0700 (PDT) In-Reply-To: <20150627175428.GA2259@muck> References: <1EF70EBC-8BB8-4A93-8591-52B2B0335F6C@petertodd.org> <20150627172011.GB18729@muck> <20150627173724.GA30546@muck> <20150627175428.GA2259@muck> Date: Sat, 27 Jun 2015 21:34:16 +0200 Message-ID: From: Benjamin To: Peter Todd Content-Type: multipart/alternative; boundary=001a11c14dc236a9d3051984f11f 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 19:34:18 -0000 --001a11c14dc236a9d3051984f11f Content-Type: text/plain; charset=UTF-8 On Sat, Jun 27, 2015 at 7:54 PM, Peter Todd wrote: > On Sat, Jun 27, 2015 at 07:46:55PM +0200, Benjamin wrote: > > 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. > > There's lots of markets where there is no assured quality of service, > and where the bids others are making aren't known. Most financial > markets work that way - there's only ever probabalistic guarantees that > for a given amount of money you'll be able to buy a certain amount of > gold at any given time for instance. Similarly for nearly all > commodities the infrastructure required to mine those commodities has > very little room for short, medium, or even long-term production > increases, so whatever the production supply is at a given time is > pretty much fixed. > hmm? if the current ask for 1 ounce of gold is 100$, then you need to bid 100$ to get 1 ounce of gold. If tomorrow everyone agree 1ounce of gold should be worth 200$, then the bid moves accordingly. of course production changes based on prices. otherwise the economy would not function. if price of some stuff goes up, more people produce that stuff. in terms of a price for a transaction and the use of a blockchain, unfortunately there is not a way to just add computational supply. that's an inherent weakness of how blockchains are structured. ideally it would be as simple as demanding more resources as in scaling a webservices with AWS. --001a11c14dc236a9d3051984f11f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Jun 27, 2015 at 7:54 PM, Peter Todd <pete@petertodd.org&g= t; wrote:
On Sat, Jun 27, 2015 = at 07:46:55PM +0200, Benjamin wrote:
> There is no ensured Quality of service, is there? If you "bid&quo= t; 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 (i= ncreasing
> increments) you can establish a feedback loop to sett= le demand and supply.
> And the supply side doesn't adapt. Adapting supply would help reso= lve parts
> of the capacity problem.

There's lots of markets where there is no assured quality of ser= vice,
and where the bids others are making aren't known. Most financial
markets work that way - there's only ever probabalistic guarantees that=
for a given amount of money you'll be able to buy a certain amount of gold at any given time for instance. Similarly for nearly all
commodities the infrastructure required to mine those commodities has
very little room for short, medium, or even long-term production
increases, so whatever the production supply is at a given time is
pretty much fixed.


hmm? = if the current ask for 1 ounce of gold is 100$, then you need to bid 100$ t= o get 1 ounce of gold. If tomorrow everyone agree 1ounce of gold should be = worth 200$, then the bid moves accordingly. of course production changes ba= sed on prices. otherwise the economy would not function. if price of some s= tuff goes up, more people produce that stuff. in terms of a price for a tra= nsaction and the use of a blockchain, unfortunately there is not a way to j= ust add computational supply. that's an inherent weakness of how blockc= hains are structured. ideally it would be as simple as demanding more resou= rces as in scaling a webservices with AWS.
--001a11c14dc236a9d3051984f11f--