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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <voisine@gmail.com>) id 1Yqohw-0001hl-GS
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 20:17:16 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.170 as permitted sender)
client-ip=209.85.216.170; envelope-from=voisine@gmail.com;
helo=mail-qc0-f170.google.com;
Received: from mail-qc0-f170.google.com ([209.85.216.170])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yqohv-0007yv-7o
for bitcoin-development@lists.sourceforge.net;
Fri, 08 May 2015 20:17:16 +0000
Received: by qcyk17 with SMTP id k17so42831932qcy.1
for <bitcoin-development@lists.sourceforge.net>;
Fri, 08 May 2015 13:17:09 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.17.21 with SMTP id b21mr11600631qkh.71.1431116229762;
Fri, 08 May 2015 13:17:09 -0700 (PDT)
Received: by 10.140.91.37 with HTTP; Fri, 8 May 2015 13:17:09 -0700 (PDT)
In-Reply-To: <1551544.DzLxgCKLBq@coldstorage>
References: <554A91BE.6060105@bluematt.me>
<20150507014952.GA5657@savin.petertodd.org>
<1551544.DzLxgCKLBq@coldstorage>
Date: Fri, 8 May 2015 13:17:09 -0700
Message-ID: <CACq0ZD6Jt2=yw=A8+bgonb3Jb2h2fgEt8aVWNeNvsOpzZr9qrQ@mail.gmail.com>
From: Aaron Voisine <voisine@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a113fe0fe81e670051597b652
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(voisine[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
1.6 MALFORMED_FREEMAIL Bad headers on message from free email service
X-Headers-End: 1Yqohv-0007yv-7o
Subject: Re: [Bitcoin-development] Block Size Increase
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2015 20:17:16 -0000
--001a113fe0fe81e670051597b652
Content-Type: text/plain; charset=UTF-8
As the author of a popular SPV wallet, I wanted to weigh in, in support of
the Gavin's 20Mb block proposal.
The best argument I've heard against raising the limit is that we need fee
pressure. I agree that fee pressure is the right way to economize on
scarce resources. Placing hard limits on block size however is an
incredibly disruptive way to go about this, and will severely negatively
impact users' experience.
When users pay too low a fee, they should:
1) See immediate failure as they do now with fees that fail to propagate.
2) If the fee lower than it should be but not terminal, they should see
degraded performance, long delays in confirmation, but eventual success.
This will encourage them to pay higher fees in future.
The worst of all worlds would be to have transactions propagate, hang in
limbo for days, and then fail. This is the most important scenario to
avoid. Increasing the 1Mb block size limit I think is the simplest way to
avoid this least desirable scenario for the immediate future.
We can play around with improved transaction selection for blocks and
encourage miners to adopt it to discourage low fees and create fee
pressure. These could involve hybrid priority/fee selection so low fee
transactions see degraded performance instead of failure. This would be the
conservative low risk approach.
Aaron Voisine
co-founder and CEO
breadwallet.com
--001a113fe0fe81e670051597b652
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">As the author of a popular SPV wallet, I wanted to weigh i=
n, in support of the Gavin's 20Mb block proposal.<div><br></div><div>Th=
e best argument I've heard against raising the limit is that we need fe=
e pressure.=C2=A0 I agree that fee pressure is the right way to economize o=
n scarce resources. Placing hard limits on block size however is an incredi=
bly disruptive way to go about this, and will severely negatively impact us=
ers' experience.<br><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra">When users pay too low a fee, they should:</div><div class=3D"=
gmail_extra"><br></div><div class=3D"gmail_extra">1) See immediate failure =
as they do now with fees that fail to propagate.</div><div class=3D"gmail_e=
xtra"><br></div><div class=3D"gmail_extra">2) If the fee lower than it shou=
ld be but not terminal, they should see degraded performance, long delays i=
n confirmation, but eventual success. This will encourage them to pay highe=
r fees in future.</div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">The worst of all worlds would be to have transactions propagate=
, hang in limbo for days, and then fail. This is the most important scenari=
o to avoid. Increasing the 1Mb block size limit I think is the simplest way=
to avoid this least desirable scenario for the immediate future.</div><div=
class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">We can play aro=
und with improved transaction selection for blocks and encourage miners to =
adopt it to discourage low fees and create fee pressure. These could involv=
e hybrid priority/fee selection so low fee transactions see degraded perfor=
mance instead of failure. This would be the conservative low risk approach.=
</div><div class=3D"gmail_extra"><br><div><div class=3D"gmail_signature"><d=
iv dir=3D"ltr"><div><div dir=3D"ltr"><div>Aaron Voisine</div><div>co-founde=
r and CEO<br><a href=3D"http://breadwallet.com" target=3D"_blank">breadwall=
et.com</a></div></div></div></div></div></div></div></div></div>
--001a113fe0fe81e670051597b652--
|
