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 21:27:27 +0100 [thread overview]
Message-ID: <CAAt2M1-JtmcMH2WCx5T5U8B-B+Ob61WPSvX4JoOcWzYFCLSTmw@mail.gmail.com> (raw)
In-Reply-To: <1518710367.3550.111.camel@mmci.uni-saarland.de>
[-- Attachment #1: Type: text/plain, Size: 2243 bytes --]
Den 15 feb. 2018 17:00 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org>:
Consensus rules
===============
A decommitment d = chal spends a UTXO with address H_addr(chal), if
there exists a commitment c in the blockchain which references the UTXO
and which is the first commitment (among all referencing the UTXO) in
the blockchain such that
1. k = KDF(chal) correctly decrypts Dec(k, c)
and
2. tx = Dec(k, c) is a valid transaction to spend UTXO
The UTXO is spent as described by tx.
Commitments never expire.
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.
Situation B: We don't allow conflicting commitments, and they never expire.
I can now freeze everybody's funds trivially with invalid commitments,
because you can't validate a commitment without seeing a valid transaction
matching it - and exposing an uncommitted transaction breaks the security
promise of commitments.
Any additional data in the commitment but hash it the transaction is
pointless, because the security properties are the same. You can't freeze
an UTXO after only seeing a commitment, and for any two conflicting
transactions you may observe it does not matter at all if one references
UTXO:s or not since you already know both transactions' commitment ages
anyway. Oldest would win no matter the additional data.
Commitments work when the network can't easily be censored for long enough
to deploy the attack (at least for 2-3 blocks worth of time). They fail
when the attacker is capable of performing such an attack.
As I said previously, the only completely solid solution in all
circumstances is a quantum resistant Zero-knowledge proof algorithm, or
some equivalent method of proving knowledge of the key without revealing
any data that enables a quantum attack.
[-- Attachment #2: Type: text/html, Size: 3211 bytes --]
next prev parent reply other threads:[~2018-02-15 20:27 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 [this message]
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
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-JtmcMH2WCx5T5U8B-B+Ob61WPSvX4JoOcWzYFCLSTmw@mail.gmail.com \
--to=natanael.l@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tim.ruffing@mmci$(echo .)uni-saarland.de \
/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