Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VZk12-0001lH-Gg for bitcoin-development@lists.sourceforge.net; Fri, 25 Oct 2013 16:13:36 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.154 as permitted sender) client-ip=62.13.148.154; envelope-from=pete@petertodd.org; helo=outmail148154.authsmtp.co.uk; Received: from outmail148154.authsmtp.co.uk ([62.13.148.154]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VZk10-0003iK-V8 for bitcoin-development@lists.sourceforge.net; Fri, 25 Oct 2013 16:13:36 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt6.authsmtp.com (8.14.2/8.14.2) with ESMTP id r9PGDSrc041666; Fri, 25 Oct 2013 17:13:28 +0100 (BST) Received: from petertodd.org (petertodd.org [174.129.28.249]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r9PGDOaN009363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 25 Oct 2013 17:13:27 +0100 (BST) Date: Fri, 25 Oct 2013 12:13:23 -0400 From: Peter Todd To: Andreas Petersson Message-ID: <20131025161323.GA15774@petertodd.org> References: <20131024143043.GA12658@savin> <20131024144358.GA17142@savin> <20131024145447.GA19949@savin> <20131025070708.GA5760@savin> <91968c56640bf7647325728f490b9257@localhost> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <91968c56640bf7647325728f490b9257@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 61be8f53-3d90-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAcUF1YAAgsB AmUbWlNeUV57W2Q7 ag1VcwRfa1RMVxto VEFWR1pVCwQmQxVh cWphA2dydwxFfn0+ ZEZjXXcVWkUoIE4r R01JFjkPZXphaTUc TRJQdwFJcANIexZF O1F6ACIKLwdSbGoL NQ4vNDcwO3BTJTpY RgYVKF8UXXNDOzc/ RhYNVTsiEAUIXDky KhU6K1kaVEwcLlk/ KzMA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 174.129.28.249/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: petertodd.org] X-Headers-End: 1VZk10-0003iK-V8 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Making fee estimation better X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 16:13:36 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 25, 2013 at 02:02:35PM +0200, Andreas Petersson wrote: >=20 >=20 > > Worth thinking about the whole ecosystem of wallets involved; they all > > have to handle double-spends gracefully to make tx replacement of any > > kind user friendly. We should try to give people a heads up that this is > > coming soon if that's your thinking. >=20 > If there is a situation where wallets are supposed to constantly monitor > the tx propagation and recreate their transactions with different fees, > this would make a lot of usecases inconvenient. > half-offline bluetooth transactions, users with unstable connections, > battery power lost, etc, etc. - and last but not least power concerns on > hardware wallets on the bitcoincard (tx signing drains a significant amou= nt > of power and should therefore only be done once) Anyway, as I've said repeatedly my problem with fee estimation is that it needs to be combined with some form of transaction replacement to give users a way to recover from bad estimates, not that I think the idea shouldn't be implemented at all. After all, we alrady have fee estimation: wallet authors and users manully estimate fees! This particular case is a nasty one re: recovering from a bad estimate, and it's exactly why the payment protocol is designed for the sender to give the receiver a copy of every transaction they make so the receiver can be held responsible for getting them mined, eg. with child-pays-for-parent, out-of-band fee payment, or maybe even by adding inputs to the transaction. (SIGHASH_ANYONECANPAY) --=20 'peter'[:-1]@petertodd.org 0000000000000001231d6e04b4b18f85fa0ad00e837727e7141eaa8cfecc734b --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJSapijAAoJEBmcgzuo5/CFZfIIAI9GyuUJaCtsLiILY3Rn/F+k tVHJQuiQNvGLWDok5FdO28saTurJRCs336gVrNuQUXDV9wXMbqTZ4sWKBNFxAHbf gy5LWhkPTUQlmhKKFKFkIDDzH3YRRZFnik/jobWAZDHiiS1VVyo2qegXgAb5KLbX kZl++bIh6WKwNzpwmPRbxh2H09ZPeMOzYE7eVZxjTJgoOhGbrmfw7wm6jyMQ/P/K CZQgRZ0qe62ye5WikpXEbavM0DosYUsW1g+nJG0z1m0RiXDBI6c5z+t53owA0Cq8 aeV1oe1xA5cBttgTmFVdy+E+x9KUaC0Y+qLe438syOUUajM6eBbohyUoyVDAiMg= =YFOu -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs--