From: Tim Ruffing <tim.ruffing@mmci•uni-saarland.de>
To: Natanael <natanael.l@gmail•com>,
Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Transition to post-quantum
Date: Fri, 16 Feb 2018 00:44:19 +0100 [thread overview]
Message-ID: <1518738259.3550.170.camel@mmci.uni-saarland.de> (raw)
In-Reply-To: <CAAt2M1-0-c1-OC0g0_6aBueR8wU+ipPw4U_zSLkdoh3K79PWsw@mail.gmail.com>
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.
next prev parent reply other threads:[~2018-02-15 23:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-12 14:13 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
2018-02-15 22:45 ` Natanael
2018-02-15 23:44 ` Tim Ruffing [this message]
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=1518738259.3550.170.camel@mmci.uni-saarland.de \
--to=tim.ruffing@mmci$(echo .)uni-saarland.de \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=natanael.l@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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