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 41701A8C for ; Sat, 24 Sep 2016 09:37:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out02.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E582C1BE for ; Sat, 24 Sep 2016 09:37:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102]) by mx-out02.mykolab.com (Postfix) with ESMTPS id ADFFA636C8; Sat, 24 Sep 2016 11:37:53 +0200 (CEST) From: Tom To: Luke Dashjr Date: Sat, 24 Sep 2016 11:37:52 +0200 Message-ID: <4508352.RUQdqZv42T@kiwi> In-Reply-To: <201609232234.43689.luke@dashjr.org> References: <201609230957.03138.luke@dashjr.org> <2403444.9CSRyRIcH2@garp> <201609232234.43689.luke@dashjr.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 24 Sep 2016 13:44:16 +0000 Cc: bitcoin-dev@lists.linuxfoundation.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: Sat, 24 Sep 2016 09:37:58 -0000 Thank you Luke, this makes it clearer. It doesn't change that this scenario is an attack that doesn't give the attacker any benefit and the attacked doesn't loose anything either (as Dave pointed out). This is a completely academical problem that assumes so many stupid mistakes from software and from people that its very unlikely. On top of that it assumes a rather lengthy 51% attack in concert with this already extremely unlikely usecase. In the scenario you assume stupid people and then you solve it by requiring the victim to suddenly be super smart and use a solution specifically designed for this super unlikely usecase that probably will never actually happen... I don't buy it. On Friday, 23 September 2016 22:34:41 CEST Luke Dashjr wrote: > Joe sends Alice 5 BTC (UTXO 0). > Fred sends Alice 4 BTC (UTXO 1). > Alice sends Bob 4 BTC using UTXO 1 (creating UTXO 2). > Fred double-spends UTXO 1 with UTXO 1-B. This invalidates Alice's > transfer to Bob. > Alice has UTXO 0 which she can send to Bob (UTXO 3), but if she does so, > it is possible that UTXO 0 could be mined, and then both UTXO 2 and UTXO > 3 which would result in her giving Bob a total of 8 BTC rather than > merely 4 BTC. Even if Alice waits until Fred's UTXO 1-B confirms 10 > blocks deep, it is not impossible for a reorganization to reverse those > 10 blocks and confirm UTXO 1 again. > Using OP_CHECKBLOCKATHEIGHT, however, Alice can create UTXO 3 such that > it is valid only in the blockchain where Fred's UTXO 1-B has confirmed. > This way, if that block is reorganized out, UTXO 3 is invalid, and > either Bob receives only the original UTXO 2, or Alice can create a UTXO > 3-B which is valid in the reorganized blockchain if it again confirms > the UTXO 1-B double-spend. > > Luke > > On Friday, September 23, 2016 2:37:39 PM Tom via bitcoin-dev wrote: > > On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoin-dev wrote: > > > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the > > > Bitcoin > > > scripting system to address reissuing bitcoin transactions when the > > > coins they spend have been conflicted/double-spent. > > > > > > https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki > > > > Can you walk us through a real live usecase which this solves? I read > > it and I think I understand it, but I can't see the attack every > > giving the attacker any benefit (or the attacked losing anything). > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev