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
|
Return-Path: <jeanpaulkogelman@me.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D041C414
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 04:07:38 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from st11p02im-asmtp001.me.com (st11p02im-asmtp001.me.com
[17.172.220.113])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 718787C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 30 Jul 2015 04:07:38 +0000 (UTC)
Received: from [10.0.1.9] (S0106b8c75dcca39e.vc.shawcable.net [24.84.203.85])
by st11p02im-asmtp001.me.com
(Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31
2015))
with ESMTPSA id <0NSA015P98SMN000@st11p02im-asmtp001.me.com> for
bitcoin-dev@lists.linuxfoundation.org;
Thu, 30 Jul 2015 04:07:37 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10432:5.14.151,1.0.33,0.0.0000
definitions=2015-07-30_03:2015-07-29, 2015-07-30,
1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
suspectscore=3 phishscore=0 adultscore=0 bulkscore=0 classifier=spam
adjust=0
reason=mlx scancount=1 engine=7.0.1-1412110000
definitions=main-1507300074
Content-type: multipart/alternative;
boundary=Apple-Mail-FA7B4473-5D81-4EB3-99D5-AAB2B67C0C74
MIME-version: 1.0 (1.0)
From: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
X-Mailer: iPhone Mail (12H143)
In-reply-to: <CAF_2MyVAXg9788gatEQ-t4=8rJxXdkf9DA45uF5_gksDUM6b=A@mail.gmail.com>
Date: Wed, 29 Jul 2015 21:07:33 -0700
Content-transfer-encoding: 7bit
Message-id: <A03FDB78-074B-4334-B56A-71593F4D7985@me.com>
References: <CADZB0_ZgDMhVgCUh2PTAPDL7k_W8QGt_HLYdkwv_qQ5xEMn8HA@mail.gmail.com>
<543015348.4948849.1438178962054.JavaMail.yahoo@mail.yahoo.com>
<COL131-DS3F7339BCCA36BEFD1755ACD8C0@phx.gbl>
<55B959A2.9020402@sky-ip.org>
<CAF_2MyVAXg9788gatEQ-t4=8rJxXdkf9DA45uF5_gksDUM6b=A@mail.gmail.com>
To: Ryan Butler <rryananizer@gmail.com>
X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,HTML_MESSAGE,
MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD 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"
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev]
=?utf-8?q?R=C4=83spuns=3A_Personal_opinion_on_the_f?=
=?utf-8?q?ee_market_from_a_worried_local_trader?=
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: Thu, 30 Jul 2015 04:07:39 -0000
--Apple-Mail-FA7B4473-5D81-4EB3-99D5-AAB2B67C0C74
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
> On Jul 29, 2015, at 8:41 PM, Ryan Butler via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
>=20
> Does an unlimited blocksize imply the lack of a fee market? Isn't every m=
iner able to set their minimum accepted fee or transaction acceptance algori=
thm?
>=20
Yes, miners can set this, and giving them more fine grained control over thi=
s (with sane defaults) will have a far bigger impact on establishing a prope=
r fee market than depending on capacity (that nobody has any control over).=20=
Allowing miners to set up some sort of tiered offering that delays transacti=
ons and maybe even have their tiers tie into the exchange rate to keep the c=
osts constant over time.
I'm sure something like this has probably already been discussed before and I=
'm curious what the objections are to such a thing?
jp=
--Apple-Mail-FA7B4473-5D81-4EB3-99D5-AAB2B67C0C74
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><br></div><div><br>On Jul 29, 2015, at=
8:41 PM, Ryan Butler via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<=
br><br></div><blockquote type=3D"cite"><div><p dir=3D"ltr">Does an unlimited=
blocksize imply the lack of a fee market? Isn't every miner able to s=
et their minimum accepted fee or transaction acceptance algorithm?</p></div>=
</blockquote><br><div>Yes, miners can set this, and giving them more fine gr=
ained control over this (with sane defaults) will have a far bigger impact o=
n establishing a proper fee market than depending on capacity (that nobody h=
as any control over). </div><div><br></div><div>Allowing miners to set u=
p some sort of tiered offering that delays transactions and maybe even have t=
heir tiers tie into the exchange rate to keep the costs constant over time.<=
/div><div><br></div><div>I'm sure something like this has probably already b=
een discussed before and I'm curious what the objections are to such a thing=
?</div><div><br></div><div>jp</div></body></html>=
--Apple-Mail-FA7B4473-5D81-4EB3-99D5-AAB2B67C0C74--
|
