diff options
| author | Benjamin <benjamin.l.cordes@gmail.com> | 2015-06-27 21:34:16 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-27 19:34:17 +0000 |
| commit | 7e0fd750d4f56dd67b040c1c0ac6db8cba391389 (patch) | |
| tree | 0d72a2cc833e09d9470d66cc0a0447fd605558f8 | |
| parent | b9c72fb3fdc62c9278cc1a095b3e3815eb0277f4 (diff) | |
| download | pi-bitcoindev-7e0fd750d4f56dd67b040c1c0ac6db8cba391389.tar.gz pi-bitcoindev-7e0fd750d4f56dd67b040c1c0ac6db8cba391389.zip | |
Re: [bitcoin-dev] A Proposed Compromise to the Block Size Limit
| -rw-r--r-- | 6e/047b8120081ff9f7ea8a7ff49c8943affcd103 | 148 |
1 files changed, 148 insertions, 0 deletions
diff --git a/6e/047b8120081ff9f7ea8a7ff49c8943affcd103 b/6e/047b8120081ff9f7ea8a7ff49c8943affcd103 new file mode 100644 index 000000000..d3f10ac86 --- /dev/null +++ b/6e/047b8120081ff9f7ea8a7ff49c8943affcd103 @@ -0,0 +1,148 @@ +Return-Path: <benjamin.l.cordes@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id E275CAB2 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 27 Jun 2015 19:34:17 +0000 (UTC) +Received: by obctg8 with SMTP id tg8so84446840obc.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CALgxB7udA85BWetBGc-RN=72ZtVPK9Q5HW8YRDKA08M38XqJqQ@mail.gmail.com> + <1EF70EBC-8BB8-4A93-8591-52B2B0335F6C@petertodd.org> + <CALgxB7usetoaNCObhG36TrdYgKuP4TSPPNkGatvim1oWUMxaeQ@mail.gmail.com> + <20150627172011.GB18729@muck> + <CAOoPuRZrV_8XJbCbHMEWAfoKYc+OSQQMuhgESgG2JD2nEHoyvQ@mail.gmail.com> + <20150627173724.GA30546@muck> + <CAOoPuRbqdWWGRL7mRReMdSct2dsiFw_X9YtNJWquZS=fsCdCDQ@mail.gmail.com> + <20150627175428.GA2259@muck> +Date: Sat, 27 Jun 2015 21:34:16 +0200 +Message-ID: <CAOoPuRaN0LJQ6_j6h6ShLbvdAnnw1-bg8BQXdOTnjp+vFN59AQ@mail.gmail.com> +From: Benjamin <benjamin.l.cordes@gmail.com> +To: Peter Todd <pete@petertodd.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <pete@petertodd.org> 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 + +<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= +te">On Sat, Jun 27, 2015 at 7:54 PM, Peter Todd <span dir=3D"ltr"><<a hr= +ef=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petertodd.org</a>&g= +t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= +px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde= +r-left-style:solid;padding-left:1ex"><span class=3D"">On Sat, Jun 27, 2015 = +at 07:46:55PM +0200, Benjamin wrote:<br> +> There is no ensured Quality of service, is there? If you "bid&quo= +t; higher, then<br> +> you don't know what you are going to get. Also because you have no= + way of<br> +</span>> knowing what *others* are bidding. Only if you have auctions (i= +ncreasing<br> +<span class=3D"">> increments) you can establish a feedback loop to sett= +le demand and supply.<br> +> And the supply side doesn't adapt. Adapting supply would help reso= +lve parts<br> +> of the capacity problem.<br> +<br> +</span>There's lots of markets where there is no assured quality of ser= +vice,<br> +and where the bids others are making aren't known. Most financial<br> +markets work that way - there's only ever probabalistic guarantees that= +<br> +for a given amount of money you'll be able to buy a certain amount of<b= +r> +gold at any given time for instance. Similarly for nearly all<br> +commodities the infrastructure required to mine those commodities has<br> +very little room for short, medium, or even long-term production<br> +increases, so whatever the production supply is at a given time is<br> +pretty much fixed.<br></blockquote><div><br></div><div><br></div><div>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.</div></div></div></div> + +--001a11c14dc236a9d3051984f11f-- + |