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 3DC05F9C for ; Wed, 24 Jan 2018 07:28:41 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148110.authsmtp.com (outmail148110.authsmtp.com [62.13.148.110]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 84AE2134 for ; Wed, 24 Jan 2018 07:28:40 +0000 (UTC) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt20.authsmtp.com. (8.15.2/8.15.2) with ESMTP id w0O7ScUS036766; Wed, 24 Jan 2018 07:28:38 GMT (envelope-from pete@petertodd.org) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id w0O7SaGu044406 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Jan 2018 07:28:37 GMT (envelope-from pete@petertodd.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id F33BC4010A; Wed, 24 Jan 2018 07:28:35 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 0AAAF209B1; Wed, 24 Jan 2018 02:28:35 -0500 (EST) Date: Wed, 24 Jan 2018 02:28:35 -0500 From: Peter Todd To: Gregory Maxwell Message-ID: <20180124072835.GB12767@savin.petertodd.org> References: <20180122200023.GA1055@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+pHx0qQiF2pBVqBT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 3176774b-00d8-11e8-8106-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAYUElQaAgsB Am4bW1NeUlV7WmQ7 bghPaBtcak9QXgdq T0pMXVMcUwUXBn9Q cVseVh12dwMIeX92 Z0MsXXFcWkN9cRRg Qk4AHXAHZDJodWge UEZFdwNVdQJNeEwU a1l3GhFYa3VsNCMk FAgyOXU9MCtqYBhP SwcWJFkOQEENVhsx XR8DGzpnXUcEX3xp clQ8J1oVDE8NM0I0 cDMA X-Authentic-SMTP: 61633532353630.1038:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 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 Protocol Discussion Subject: Re: [bitcoin-dev] Transaction Merging (bip125 relaxation) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 07:28:41 -0000 --+pHx0qQiF2pBVqBT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 23, 2018 at 09:31:00PM +0000, Gregory Maxwell wrote: > On Mon, Jan 22, 2018 at 8:00 PM, Peter Todd via bitcoin-dev > wrote: > > Most transactions don't have change?! Under what circumstance? For most > > use-cases the reverse is true: almost all all transactions have change,= because > > it's rare for the inputs to exactly math the requested payment. >=20 > It's quite easy to get no change with a not-dumb algorithm selecting > coins if you have a decent number of outputs well under the value > you're paying. >=20 > The number of ways n choose m combines grows exponentially, and you > only need to get close enough over the right value so that you're > paying excess fees equal or less than the cost of the change (which > should include the current cost output itself as well as estimated > cost of the future signature to spend it). >=20 > Achow101 and Murch have code to implement an efficient algorithm for > finding these solutions for Bitcoin core which will hopefully get in > soon. Oh, Bitcoin Core doesn't already do that? I though that was what the (rather complex) knapsack code was supposed to be doing. In any case, you're assuming that there actually are a large number of outp= uts. That's not likely to be the case in most "consumer-like" use-cases where the number of deposits into the wallet is relatively low compared to the number= of withdrawls as coins are spent in smaller amounts; that's the pattern most o= f my Bitcoin usage follows, particularly as I keep the amount of funds in my hot wallets low. Having said that, Rhavar's usage patterns could easily be different; I'd be completely wrong in the case of a payment service for instance where a large number of deposits are aggregated into a smaller number of payments; that use-case happens to be a particularly interesting one for using tx replacem= ent to add outputs, so my criticism was definitely premature. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --+pHx0qQiF2pBVqBT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaaDWfAAoJECSBQD2l8JH7UUwIAKNFzcTR1CV+3sRuIbJJSMOv UFUPblJVbbkOcr/Qz0q3QYKf9J3TjtMrrKP+2KI+Weh1ZHGfPM05ZQJZP7PbfuAQ BDTcenglQK3bx164NReAOwt08rFXjZZ6JFSIcxaQfmEGV82tXu6tpT9czsG1QW3p s6NCu/99YkJpBQe23DsMa0G0HXrhHpNVOXWWqCUJ1WhV7WrxFxlmSkTc+PvPB6nF MVqch/PVWq8auc+cbCU96j7ldBndBNGKw/Yvo0EpeTm8oYJ07kYWNLtHYqw7hHu9 Z1lJFslxWuFaWYDaT006kPFq2wYuGL4wzqkr8RzQLic4d+WjF1OCVBuAZxjTZ+Q= =hv1t -----END PGP SIGNATURE----- --+pHx0qQiF2pBVqBT--