Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CD89FAF3 for ; Tue, 30 Jun 2015 14:03:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.dtrt.org (mail.dtrt.org [207.192.75.234]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7CD6C181 for ; Tue, 30 Jun 2015 14:03:33 +0000 (UTC) Received: from harding by mail.dtrt.org with local (Exim 4.72) (envelope-from ) id 1Z9w8J-0004wX-JX; Tue, 30 Jun 2015 10:03:31 -0400 Date: Tue, 30 Jun 2015 10:02:13 -0400 From: "David A. Harding" To: Adam Back Message-ID: <20150630140213.GA22557@localhost.localdomain> References: <20150629050726.GA502@savin.petertodd.org> <5591E10F.9000008@thinlink.com> <20150630013736.GA11508@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD 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] BIP: Full Replace-by-Fee deployment schedule 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: Tue, 30 Jun 2015 14:03:33 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 30, 2015 at 03:12:52PM +0200, Adam Back wrote: > Any thoughts on the simplest way to support an opt-in version of full-RBF? Bundle it in with BIP62 version-2 (or whatever) transactions. - As you desire for RBF, the BIP62 transactions are already specified to be opt-in. Nobody has to use them. - Although BIP62 transactions only prevent third-party mutation, some people might wrongly assume that they prevent all mutation---including double spending. We need to make it clear that even with BIP62 transactions, signers can still mutate their own transactions---and what better way to do that than make BIP62 transactions easier to double spend? The downside I see is possible further delay of full BIP62. Although, I guess it could go the other way too by having developers who want RBF help push BIP62 into production. -Dave --=20 David A. Harding --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVkqFlAAoJEEspww/ynsS3gfwH/Aiy3Wrn4hsi/l6ceh2ajV3k r0ub5HW3LZXUO5sBKJA9WpFXM5hQmIVGjkV2JHGWVqBaLjsjhL2StS5UKdWYPLVq OwSXymr3XeuKq11vcm0WtLsn5+GulAnPZRusITOXwqZwbkGPJ3JTE2R5Wt4eQBrm GJ1SHFl8oAXHSMITP6AWTg+bFzjSUrfg07+9oRRvlMDFGh1NYfBTWAstZbmH6uHJ YH02rDEOsgCupS4DjdRBwyAK97X0jvvczok7aPgtAitYnT0X0tLtjejul55qaPT3 rLk82Ay8VfllTaFt1qmylVpoSK5ka6ha/4vof5RtBeDXCwAuRJ8OV36xNb02wKM= =ypwQ -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j--