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 6CF2FFEC for ; Thu, 15 Feb 2018 22:44:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D0DF9D3 for ; Thu, 15 Feb 2018 22:44:07 +0000 (UTC) Received: by mail-wm0-f51.google.com with SMTP id x21so62037wmh.0 for ; Thu, 15 Feb 2018 14:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FySVwj1WG1AlAchT+Nai19jusgEPoQdr8CLbqSGQvlg=; b=OGh2tGe36HrgfY92jkHR7dYWlqgSCvfm1IgyCQykiiaXxoJH6x4cuWtG0Oj3xwvcCt 9VOvNZsmbu1R8J8dQ9rJZgbGJH9qZ/+TwnMZJgkxjBYdrRzgoiUaUOMSOxYjsHv73NcW npSpG1Vd2A7/Uy17miSwEHA3h+uEPUO69GpTie20YhBiuIbDBR/TmdI3zj7zOOsSNjDv 9V3noa15Ln77gQjUlvOhCb/piRQsYVAYVgOXusFCXsoVDLYrkvZBy7uyRVqZkhI/mpG3 LzZ8aOg8fwSVK2vcH3OHV/0Y1yXuZUBFUfkjimRtaakAfW/WqPdlhAtAuGNB1nhijt0y La6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=FySVwj1WG1AlAchT+Nai19jusgEPoQdr8CLbqSGQvlg=; b=ai6uApaCYSMkRlC13Ff+aNSzgYOaPCFXUc/G7DrbmYWTiZ3QvQfDYtPyYKNjjNA3Vg TA/Fm4rUSsXFRlB27EjA3Zvyml7tJr9Cink8zUqSZg8roCaR4n3nqY2GZSah1aZ9zEIY f8jt++mFPPqmwdsyUj29ynez95DLfWGOLOO805O1jpfLnZ5qjc4UWMRmBtHzobcSh7Gk RxgLVaIdtZXXpoK5OQpdU3wzSkZ37FcvlrZQHyTi0qSuJ6jjFvDyg52ema/EkiV/rRVn KBzzti+irWQpyRsS5aNlQAG3q/9mp5W9CT4m0XpprGAKOrZNVTWnF5DdWTNFTEV0iAyY 3LeQ== X-Gm-Message-State: APf1xPC6Td/Qk2tDUu96EndON4D6urMVFYpJDwjriHTsmVN2rOF74mPA CaeE17Pw9MADjK8s7O159K27j3Xw8P+U97IQKFs= X-Google-Smtp-Source: AH8x225+si61Hghs0OR/42LGhq96WjM3xx6JneCrcYV25PSNvkIZFlI9n4rO0ACo46tvV30rGE2tr8fzez+MckehXw0= X-Received: by 10.80.151.137 with SMTP id e9mr5391106edb.102.1518734646425; Thu, 15 Feb 2018 14:44:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.169.74 with HTTP; Thu, 15 Feb 2018 14:44:05 -0800 (PST) Received: by 10.80.169.74 with HTTP; Thu, 15 Feb 2018 14:44:05 -0800 (PST) In-Reply-To: <1518731861.3550.131.camel@mmci.uni-saarland.de> 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> From: Natanael Date: Thu, 15 Feb 2018 23:44:05 +0100 Message-ID: To: Tim Ruffing , Bitcoin Dev Content-Type: multipart/alternative; boundary="f403045c268e1bc01d056547f7e4" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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 22:44:08 -0000 --f403045c268e1bc01d056547f7e4 Content-Type: text/plain; charset="UTF-8" Den 15 feb. 2018 22:58 skrev "Tim Ruffing via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: 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. 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); Allowing expiration retains insecurity, while 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. Like I said in the other thread, this is unreasonable. It's much more practical with simple hash commitment that you can "fold away" in a Merkle tree hash and which you don't need to validate until the full transaction is published. --f403045c268e1bc01d056547f7e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Den 15 feb. 2018 22:58 skrev "Tim Ruffing via bitcoin-dev&qu= ot; <bitcoin-de= v@lists.linuxfoundation.org>:

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.
=
If your argument is that we publish the full tr= ansaction minus the public key and signatures, just committing to it, and t= hen revealing that later (which means an attacker can't modify the tran= saction in advance in a way that produces a valid transaction);

Allowing expiration retains insecur= ity, while allowing expiration makes it a trivial DoS target.=C2=A0

Anybody can flood the miners wi= th invalid transaction commitments. No miner can ever prune invalid commitm= ents until a valid transaction is finalized which conflicts with the invali= d commitments. You can't even rate limit it safely.=C2=A0

Like I said in the other thread, this= is unreasonable. It's much more practical with=C2=A0 simple hash commi= tment that you can "fold away" in a Merkle tree hash and which yo= u don't need to validate until the full transaction is published.=C2=A0=
--f403045c268e1bc01d056547f7e4--