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 EE7C9F9F for ; Thu, 15 Feb 2018 21:57:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from jupiter.mpi-klsb.mpg.de (srv-40-61.mpi-klsb.mpg.de [139.19.86.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1B38AD3 for ; Thu, 15 Feb 2018 21:57:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mmci.uni-saarland.de; s=mail200803; h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID; bh=xmL/sA8sF5dmkljaULAFVqVeGu0uZtS73GCXfF3uaEk=; b=bZgmTBXT76DSauqdSpdEdZuSJEQ+wGx+Y7SHef7bwrXMJBH26V5yjOfbgPu8QS19x9GQFDYr2w5oADm65BeW/ur2j9mms9DBeps2oAlcUKjslsrUC10A8ika7Bmd/Wuu/EQuKKT2tWDk7t7L0rFi/6erBWZx3QBlgOPBTcHW4AY=; Received: from sam.mpi-klsb.mpg.de ([139.19.86.26]:46506) by jupiter.mpi-klsb.mpg.de (envelope-from ) with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) id 1emRXC-0004DT-0v for bitcoin-dev@lists.linuxfoundation.org; Thu, 15 Feb 2018 22:57:43 +0100 Received: from x590ec036.dyn.telefonica.de ([89.14.192.54]:44412 helo=tonno.fritz.box) by sam.mpi-klsb.mpg.de (envelope-from ) with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) id 1emRXB-0006Ak-Oq for bitcoin-dev@lists.linuxfoundation.org; Thu, 15 Feb 2018 22:57:41 +0100 Message-ID: <1518731861.3550.131.camel@mmci.uni-saarland.de> From: Tim Ruffing To: Bitcoin Dev Date: Thu, 15 Feb 2018 22:57:41 +0100 In-Reply-To: References: <1518450650.7829.87.camel@mmci.uni-saarland.de> <1518504374.9878.24.camel@mmci.uni-saarland.de> <882306fa-3ea0-99bd-61c6-f646d27c2ab6@gmail.com> <1518710367.3550.111.camel@mmci.uni-saarland.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-MPI-Local-Sender: true X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_MED 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] Transition to post-quantum 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: Thu, 15 Feb 2018 21:57:47 -0000 On Thu, 2018-02-15 at 21:27 +0100, Natanael wrote: > I addressed this partially before, and this is unfortunately > incomplete. > > Situation A: Regardless of expiration of commitments, we allow > doubles. (Or no doubles allowed, but commitments expire.) > > If I can block your transaction from confirming (censorship), then I > can make my own commitment + transaction. The miners will see two > commitments referencing the same UTXO - but can see only one > transaction which match a valid challenge and spends them, which is > mine. You gained nothing from the commitment. Yes, I assume situation A: * commitments never expire * and there is no limit on the number of commitment for the same UTXO As I understand, you mean "decommitment" when you say "transaction". Please correct me if I'm wrong. I'll stick with "decommitment". Let's assume the attacker blocks the decommitment by the honest user, inserts his own malicious commitment and his own decommitment, which should be valid for the malicious commitment. Then the miners will see two commitments (the earlier commitment by the honest user and the later one by the attacker). Also, the miners will indeed see one valid decommitment. This decommitment may have been sent by the attacker but it's the preimage chal of the address, because otherwise it's not valid for the malicious commitment. But if the decommitment is chal, then this decommitment is also valid for the commitment of the honest user, which is earliest additionally. So the honest commitment wins. The attacker does not succeed and everything is fine. The reason why this works: There is only one unique decommitment for the UTXO (assuming H_addr is collision-resistant). The decommitment does not depend on the commitment. The attacker cannot send a different decommitment, just because there is none. Maybe I'm wrong and I just don't understand your attack. In this case, please explain it more detail. Regards, Tim