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 D653FC64 for ; Mon, 22 Jan 2018 20:00:29 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148113.authsmtp.com (outmail148113.authsmtp.com [62.13.148.113]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 954A8271 for ; Mon, 22 Jan 2018 20:00:28 +0000 (UTC) Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247]) by punt24.authsmtp.com. (8.15.2/8.15.2) with ESMTP id w0MK0Q7u061526; Mon, 22 Jan 2018 20:00:26 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 w0MK0Ovh073219 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Jan 2018 20:00:25 GMT (envelope-from pete@petertodd.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 2D71C400F7; Mon, 22 Jan 2018 20:00:24 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 5D9C8209B1; Mon, 22 Jan 2018 15:00:23 -0500 (EST) Date: Mon, 22 Jan 2018 15:00:23 -0500 From: Peter Todd To: Rhavar , Bitcoin Protocol Discussion Message-ID: <20180122200023.GA1055@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: e334c842-ffae-11e7-8106-0015176ca198 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAAUElQaAgsB Am4bWVReUF17W2Y7 bghPaBtcak9QXgdq T0pMXVMcUwUVehx+ QEYeVRpwdgwIcHZz Zwg3XXNfD0x+d1sr FB8BCGwHMGB9YGEf Vl1YdwJRcQRMLU5E Y1gxNiYHcQ5VPz4z GA41ejw8IwAXFD5c RBoEJk4TRkBDOzMm SBEEEn1vF0wdHn9u ZwYrLlcMFVoQNUNz WQAA 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 X-Mailman-Approved-At: Mon, 22 Jan 2018 20:10:59 +0000 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: Mon, 22 Jan 2018 20:00:29 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote: > So my half-baked idea is very simple: >=20 > Allow users to merge multiple unconfirmed transactions, stripping extrane= ous inputs and change as they go. >=20 > This is currently not possible because of the bip125 rule: > "The replacement transaction pays an absolute fee of at least the sum pai= d by the original transactions." >=20 > Because the size of the merged transaction is smaller than the original t= ransactions, unless there is a considerable feerate bump, this rule isn't p= ossible to observe. >=20 > I my question is: is it possible or reasonable to relax this rule? If thi= s rule was removed in its entirety, does it introduce any DoS vectors? Or c= an it be changed to allow my use-case? It would definitely introduce DoS vectors by making it much cheaper to use relay bandwidth. You'd also be able to push others' txs out of the mempool. > --- > Full backstory: I have been trying to use bip125 (Opt-in Full Replace-by-= Fee) to do "transaction merging" on the fly. Let's say that I owe John 1 bi= tcoin, and have promised to pay him immediately: Instead of creating a whol= e new transaction if I have an in-flight (unconfirmed) transaction, I can f= ollow the rules of bip125 to create a replacement that accomplishes this go= al. >=20 > From a "coin selection" point of view, this was significantly easier than > I had anticipated. I was able to encode the rules in my linear model and > feed in all my unspent and in-flight transactions and it can solve it wit= hout difficulty. >=20 > However, the real problem is tracking the mess. Consider this sequence of= events: > 1) I have unconfirmed transaction A > 2) I replace it with B, which pays John 1 BTC > 3) Transaction A gets confirmed >=20 > So now I still owe John 1 BTC, however it's not immediately clear if > it's safe to send to him without waiting $n transactions. However even > for a small $n, this breaks my promise to pay him immediately. > > One possible solution is to only consider a transaction "replaceable" if = it has change, so if the original transaction confirms -- payments can imme= diately be made that source the change, and provide safety in a reorg. >=20 > However, this will only work <50% of the time for me (most transactions > don't have change) and opens a pandora's box of complexity. Most transactions don't have change?! Under what circumstance? For most use-cases the reverse is true: almost all all transactions have change, bec= ause it's rare for the inputs to exactly math the requested payment. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaZkLRAAoJECSBQD2l8JH7f84IAIHgCCqvqQabIi/h1uxTBUuV ucazL47BXF9PfPCCyM6ukX34Kw1Qkww9qsEFfHWk6sIQ1usF6nAUujHKbuYlpjoy R/AHwgFcbUymC+MaEPd3N9Bl8MpDmOzD0eS0BCdZauQ4X86wUat0A2+VLNkukp28 00TG+S542Q/Gup+i+awU30XQELaHsMhEY+cKCcuz70gRUX6b6pjHKQnzN7b93dnS 6k0dArgd8fn+Y2VRTY9UYjZJQneuGfcIEPJGVOkQW2C809jEK27JWkC5PZZg8BUw 5FzU3/oSjE26gVDfHQGQgOshkQXNjQzMZmBsDDjMbybQvdVsYP0kXtXP/v4tvpk= =me3p -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA--