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
|
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 70A34BC8
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 27 Jun 2015 17:46:55 +0000 (UTC)
Received: by oigb199 with SMTP id b199so94599898oig.3
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <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>
Date: Sat, 27 Jun 2015 19:46:55 +0200
Message-ID: <CAOoPuRbqdWWGRL7mRReMdSct2dsiFw_X9YtNJWquZS=fsCdCDQ@mail.gmail.com>
From: Benjamin <benjamin.l.cordes@gmail.com>
To: Peter Todd <pete@petertodd.org>
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 <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 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 <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 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
<div dir=3D"ltr">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 <i>others</i>=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><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sat, Jun 27, 20=
15 at 7:37 PM, Peter Todd <span dir=3D"ltr"><<a href=3D"mailto:pete@pete=
rtodd.org" target=3D"_blank">pete@petertodd.org</a>></span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><span class=3D"">On Sat, Jun 27, 2015 at 07:26=
:00PM +0200, Benjamin wrote:<br>
> "Thus we have a fixed capacity system where access is mediated by=
supply<br>
> and demand transaction fees."<br>
><br>
> There is no supply and demand. That would mean users would be able to =
adapt<br>
> fees and get different quality of service depending on current capacit=
y.<br>
> For example if peak load is 10x average load, then at those times fees=
<br>
> would be higher and users would delay transactions to smooth out deman=
d.<br>
<br>
</span>That's exactly how Bitcoin works already. See my article on how<=
br>
transaction fees work for more details:<br>
<br>
<a href=3D"https://gist.github.com/petertodd/8e87c782bdf342ef18fb" rel=3D"n=
oreferrer" target=3D"_blank">https://gist.github.com/petertodd/8e87c782bdf3=
42ef18fb</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
'peter'[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24<br>
</div></div></blockquote></div><br></div>
--047d7bd6c512430986051983717d--
|
