public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Natanael <natanael.l@gmail.com>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>,
	 Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Transition to post-quantum
Date: Thu, 15 Feb 2018 23:44:05 +0100	[thread overview]
Message-ID: <CAAt2M1-0-c1-OC0g0_6aBueR8wU+ipPw4U_zSLkdoh3K79PWsw@mail.gmail.com> (raw)
In-Reply-To: <1518731861.3550.131.camel@mmci.uni-saarland.de>

[-- Attachment #1: Type: text/plain, Size: 1623 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2448 bytes --]

  reply	other threads:[~2018-02-15 22:44 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-12 14:13 [bitcoin-dev] Transition to post-quantum Tristan Hoy
2018-02-12 15:50 ` Tim Ruffing
2018-02-12 21:32   ` Tristan Hoy
2018-02-13  6:46     ` Tim Ruffing
2018-02-13 10:06       ` Tristan Hoy
2018-02-15 15:59         ` Tim Ruffing
2018-02-15 20:27           ` Natanael
2018-02-15 21:57             ` Tim Ruffing
2018-02-15 22:44               ` Natanael [this message]
2018-02-15 22:45                 ` Natanael
2018-02-15 23:44                 ` Tim Ruffing
2019-10-24 15:34                   ` Erik Aronesty

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAAt2M1-0-c1-OC0g0_6aBueR8wU+ipPw4U_zSLkdoh3K79PWsw@mail.gmail.com \
    --to=natanael.l@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=tim.ruffing@mmci.uni-saarland.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox