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
149
150
151
152
153
154
155
156
157
158
159
160
161
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 19380ACB
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 19:36:39 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148096.authsmtp.net (outmail148096.authsmtp.net
[62.13.148.96])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 3D89B144
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2015 19:36:38 +0000 (UTC)
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5QJaZoN021910;
Fri, 26 Jun 2015 20:36:35 +0100 (BST)
Received: from muck (static-71-247-144-172.nycmny.east.verizon.net
[71.247.144.172]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5QJaVWY036633
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Fri, 26 Jun 2015 20:36:33 +0100 (BST)
Date: Fri, 26 Jun 2015 15:36:30 -0400
From: Peter Todd <pete@petertodd.org>
To: Ross Nicoll <jrn@jrn.me.uk>
Message-ID: <20150626193630.GB17829@muck>
References: <CAPg+sBjOj9eXiDG0F6G54SVKkStF_1HRu2wzGqtFF5X_NAWy4w@mail.gmail.com>
<CADm_Wca+ow4pMzN7SyKjsMdFo0wuUerYYjf5xKs5G_2Q2PzMmA@mail.gmail.com>
<CAPg+sBg=sn7djO_8H16NDg7S7m7_0eTcrgLVofMWQ2ANz+jw9w@mail.gmail.com>
<CADm_WcbQog_UCV=JPHyqTRxKbaGY7jedtHE_D8jJSe_thMg05w@mail.gmail.com>
<CAPg+sBhrBUSfPdMjbLthLEFD17zBC3LoWf9LvZsOD1Vp0D78BQ@mail.gmail.com>
<558DA56F.3010703@jrn.me.uk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="gj572EiMnwbLXET9"
Content-Disposition: inline
In-Reply-To: <558DA56F.3010703@jrn.me.uk>
X-Server-Quench: a6fbebbf-1c3a-11e5-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAQUEkAaAgsB AmMbWVReU1t7WmA7 bAtPbwFafEtKWxtr
V0pWR1pVCwQmRRlg fE94NXBydANAe30+ ZEVnWHAVDUIsJxMv
EBhJFD4FNHphaTUa TRJbfgVJcANIexZF O1F6ACIKLwdSbGoL
FQ4vNDcwO3BTJTpg Cj0NIBoUTEsHVjA7 XVgGFC8gEFdNTSE0 JB89Ql4B
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 71.247.144.172/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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] The need for larger blocks
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: Fri, 26 Jun 2015 19:36:39 -0000
--gj572EiMnwbLXET9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jun 26, 2015 at 08:18:07PM +0100, Ross Nicoll wrote:
> I'd argue that at the point where there's consistently more
> transactions than the network can handle, there are two significant
> risks. Firstly, that people don't care enough to pay the transaction
> fees required to get their transaction prioritised over another's,
> and secondly that as transactions start outright failing (which will
> happen with enough transactions backlogged) the network is
> considered unreliable, the currency illiquid, and there's a virtual
> "bank rush" to get into a more usable currency.
The supply and demand fee market means that there is a range of
reliability levels depending on what fee you pay; regardless of how high
demand is if you pay a sufficiently high fee that outbids less
important/lower fee transactions you'll get reliable transaction
confirmaiton.
The perceived lack of reliability is a function of the poor state of
wallet software, not an inherent problem with the system. Fixing that
software is much easier and much less risky than any hard-fork ever will
be.
=46rom my article on transaction fees during the CoinWallet.eu flood:
What needs to be done
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Transaction fees aren't going away, blocksize increase or not. CoinWallet.e=
u is
only spending $5k flooding the network; even an 8MB blocksize increase can =
only
raise the cost of that attack to $40k, which is still very affordable. For
instance an attacker looking to manipulate the Bitcoin price could probably
afford to spend $40k doing it with the right trading strategy; let alone
governments, banks, big businesses, criminal enterprises, etc. to whom $40k=
is
chump-change. Wallets need to become smarter about fees, as does the rest of
the Bitcoin community.
What we need to do:
* Add fee/KB displays to block explorers.
* Change wallets to calculate and set fees in fee/KB rather than fixed fees=
regardless of tx size.
* Make websites with easy to understand displays of what the current mempool
backlog is, and what fee/KB is needed to get to the front of the queue. W=
e've
done a great job for Bitcoin price charts, let's extend that to transacti=
on
fees.
* Add the ability to set any fee/KB to wallets, rather than be stuck with
predefined options that may not be high enough.
* Add support for fee-bumping via (FSS)-RBF to wallets and Bitcoin Core.
Capacity limits are just a fact of life in the design of the Bitcoin protoc=
ol,
but that doesn't mean we can't give users the tools to deal with them
intelligently.
-https://gist.github.com/petertodd/8e87c782bdf342ef18fb
--=20
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24
--gj572EiMnwbLXET9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVjam7XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwMDdmYzEzY2UwMjA3MmQ5Y2IyYTZkNTFmYWU0MWZlZmNk
ZTdiM2IyODM4MDNkMjQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udwPoAf/dUbFztm/OwfokDUhxZKsKfaK
7hUfggmk7HGk45C5cWcv50U2akqH25B8NQdjSlVDyK5X7xVxop4zd3Qvh6GeKTnK
QgZg21TqMZNptxh8EhNFvWhExUjsatlaAh59ZEn+72GUdnVBbpKftuX8BJOHRKg8
KlbM4tCA+JlOFi81bGShEbhZOtGP2GBW9AJwBDDW274+qN9f11be7UX6kvN2xORB
ynN3pSMJ+B/n2bdSvSXwaiDggv3QpvsIAkvEQvAUVxEsVdcDUjLTQYnqfx/TXtD6
cqwMtxHyiLJOEILU9unmk3y8k56g+lLl8K31oTlrsdXcffS8OPK3ZXqkmFyOIg==
=nV/7
-----END PGP SIGNATURE-----
--gj572EiMnwbLXET9--
|
