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 E91A0CA6 for ; Fri, 23 Sep 2016 20:02:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149095.authsmtp.com (outmail149095.authsmtp.com [62.13.149.95]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 4318928E for ; Fri, 23 Sep 2016 20:02:29 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt24.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u8NK2S9r012857; Fri, 23 Sep 2016 21:02:28 +0100 (BST) 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.14.2/8.14.2/) with ESMTP id u8NK2P4N039664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2016 21:02:26 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 63A8F40192; Fri, 23 Sep 2016 19:58:39 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 936E42051F; Fri, 23 Sep 2016 16:02:23 -0400 (EDT) Date: Fri, 23 Sep 2016 16:02:23 -0400 From: Peter Todd To: Gregory Maxwell , Bitcoin Protocol Discussion Message-ID: <20160923200223.GA24227@fedora-21-dvm> References: <201609230957.03138.luke@dashjr.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: a675b47a-81c8-11e6-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAEUC1AEAgsB AmAbWVVeUF97W2U7 bghPaBtcak9QXgdq T0pMXVMcUQ0Weh5h AmAeURB0cQEIcH1z bQgzWHdeDkB9JFt1 Qx1cCGwHMGF9YGIW BV1YdwJRcQRDe0tA b1YxNiYHcQ5VPz4z GA41ejw8IwAXAgVt Cg0XJFwOEw4sJgkX Zz0pPh8LOmYmbhkT Aj0JCmJ0 X-Authentic-SMTP: 61633532353630.1037: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 Subject: Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT 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: Fri, 23 Sep 2016 20:02:32 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 23, 2016 at 06:57:57PM +0000, Gregory Maxwell via bitcoin-dev w= rote: > On Fri, Sep 23, 2016 at 1:43 PM, Russell O'Connor via bitcoin-dev > wrote: > > I believe Bitcoin currently enjoys the property that during an "innocen= t" > > re-org, i.e. a reorg in which no affected transactions are being double > > spent, all affected transactions can always eventually get replayed, so= long > > as the re-org depth is less than 100. >=20 > > My concern with this proposed operation is that it would destroy this > > property. >=20 > The reorg safety impact of this proposal could be eliminated and the > mempool handling complexity greatly reduced if the transaction was > required to be locktimed at least 100 blocks after the block its > referencing. However, by doing that we'd also make the functionality not all that useful= for this application; by the time you waited 100 blocks for the tx to be minabl= e, the chance of a reorg happening is low enough that I can't imagine many - if any - wallets would bother using the opcode in the first place, and would instead just rely on the fact that a reorg that deep which resulted in the double-spent transaction ending up back in the chain is very unlikely. Specifically I'm referring to the following scenario: 1) Alice pays Bob with tx1a 2) tx1a gets N confirmations, where N is some small number of confirmations. 2) Bob pays Charlie from tx1a's output in tx2a 3) A reorg eliminates the block that tx1a existed, and a conflicting tx1b is mined instead, making tx1a and tx2a invalid. 4) Bob pays Charlie again with tx2b, whose inputs do not conflict with tx2a 5) Another reorg eliminates tx1b, allowing tx1a, tx2a, and tx2b to all be mined. 6) Charlie has now been paid twice. Since you need _two_ reorgs for this scenario to be applicable, it's much easier to just wait for tx1b to be confirmed suffiently deeply in the chain that a reorg undoing it - thus allowing tx1a and tx2a to exist - is sufficiently unlikely; 100 blocks is a lot more than most wallets are goin= g to consider "sufficiently unlikely", so the featureu just won't get used (assu= ming wallets even bother to handle this case of course!). Unfortunately I think this is an inherent catch-22 of the idea. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJX5YpMAAoJEGOZARBE6K+yVjIH/iywSzjGCl4aFuTd6w4UqUfL CRnmhwdlH5GEpxKePJinC0kom1eY4Fo2uzK/J7LK9k1ALKbBBEfy88lKiLfj3BIE Ic7nDAdAayVAZSok86K/C5RqGDx/YSzJHgnfSHwH7LHajrPYWXqPg54fCVHYWQWa SggNLmrDzzBhdL6Z2bNp/eeYNcGbySI0UZv9SLTo64NvTd7g79HAJPe/bTy3t+bR FmZRadkMq5VSIhA5/Ttz9m4rNPE09eGI8fhhVovu3hDDDG8+jvkfDIYLyMDn6L15 tkA4cV2Idmal5f7dNfEjLckh1AgV52AQlC/1npVCRETHoHY5ySgpL5ucx/rJB5c= =mxwq -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4--