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 BF3CDECC for ; Thu, 15 Feb 2018 23:44:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from jupiter.mpi-klsb.mpg.de (jupiter.mpi-klsb.mpg.de [139.19.86.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 301FF48B for ; Thu, 15 Feb 2018 23:44:24 +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=D7JfXYvFEQKcE+Le82cUczlz2xNuAb1S8jeAtT8fmew=; b=rKdQDdrY/EIvjPdxxVGPZH3ivIUqYZ7BJH6fBqT6GhIoVGsAJKFTingyz8b5b+P+uefpwYHa8cqYczDfHtyocQvdRpcj7KAWGGvfYzHFyy8ROk64W3mC1zfYw5v10SbTSIs4mP8OWM7PXCgEi2g6fZp5nGgXtQlSYMVeoLb/GPA=; Received: from sam.mpi-klsb.mpg.de ([139.19.86.26]:53472) by jupiter.mpi-klsb.mpg.de (envelope-from ) with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) id 1emTCO-0006jz-Dh; Fri, 16 Feb 2018 00:44:22 +0100 Received: from x590ec036.dyn.telefonica.de ([89.14.192.54]:45116 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 1emTCO-0002Jj-5J; Fri, 16 Feb 2018 00:44:20 +0100 Message-ID: <1518738259.3550.170.camel@mmci.uni-saarland.de> From: Tim Ruffing To: Natanael , Bitcoin Dev Date: Fri, 16 Feb 2018 00:44:19 +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> <1518731861.3550.131.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 23:44:24 -0000 On Thu, 2018-02-15 at 23:44 +0100, Natanael wrote: > If your argument is that we publish the full transaction minus the > public key and signatures, just committing to it, and then revealing > that later (which means an attacker can't modify the transaction in > advance in a way that produces a valid transaction); Almost. Actually we reveal the entire transaction later. > > [...] while *NOT* allowing expiration makes it a trivial DoS target. > > Anybody can flood the miners with invalid transaction commitments. No > miner can ever prune invalid commitments until a valid transaction is > finalized which conflicts with the invalid commitments. You can't > even rate limit it safely. Yes, that's certainly true. I mentioned that issue already. You can rate limit this: The only thing I see is that one can require transaction fees even for commitments. That's super annoying, because you need a second (PQ-)UTXO just to commit. But it's not impossible. You can call this impractical and this may well be true. But what will be most practical in the future depends on many parameters that are totally unclear at the moment, e.g., the efficiency of zero-knowledge proof systems. Who knows? If you would like to use zero-knowledge proofs to recover an UTXO with an P2PKH address, you need to prove in zero-knowledge that you know some secret key x such that H(g^x)=addr. That seems plausible. But P2PKH is by far the simplest example. For arbitrary scripts, this can become pretty complex and nasty, even if our proof systems and machines are fast enough.