From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 19380ACB for ; 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 ; 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 To: Ross Nicoll Message-ID: <20150626193630.GB17829@muck> References: <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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--