1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
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--
|
