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] Taproot: Privacy preserving switchable scripting
Date: Thu, 25 Jan 2018 01:09:31 +0100 [thread overview]
Message-ID: <CAAt2M19UObuaaODHXb+iW9bWMj53wGHAdjVzZgWBi-ZCCUi4Mg@mail.gmail.com> (raw)
In-Reply-To: <1516836125.5969.11.camel@mmci.uni-saarland.de>
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]
Den 25 jan. 2018 00:22 skrev "Tim Ruffing via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org>:
I think you misread my second proposal. The first step is not only to
publish the hash but to publish a *pair* consisting of the hash and the
transaction.
If the attacker changes the transaction on the wire, the user does not
care and will try again.
I guess I assumed you meant it otherwise because I didn't assume you
intended a commitment to the full transaction just without the asymmetric
key material.
You could treat it the same way as in my suggestion, let it expire and
prune it if the key material isn't published in time.
However... A sufficiently powerful attacker can deploy as soon as he sees
your published signature and key, delay its propagation to the miners,
force expiration and then *still* repeat the attack with his own forgery.
Honestly, as long as we need to allow any form of expiry + relying on
publication of the vulnerable algorithms result for verification, I think
the weakness will remain.
No expiration hurts in multiple ways like via DoS, or by locking in
potentially wrong (or straight up malicious) transactions.
---
There's one way out, I believe, which is quantum safe Zero-knowledge
proofs. Currently STARK:s are one variant presumed quantum safe. It would
be used to completely substitute the publication of the public key and
signatures, and this way we don't even need two-step commitments.
It does however likely require a hardfork to apply to old transactions. (I
can imagine an extension block type softfork method, in which case old
UTXO:s get locked on the mainchain to create equivalent valued extension
block funds.)
Without practical ZKP, and presuming no powerful QC attackers with the
ability to control the network (basically NSA level attackers), I do think
the Fawkes signature scheme is sufficient. Quantum attacks are likely to be
very expensive anyway, for the foreseeable future.
[-- Attachment #2: Type: text/html, Size: 2812 bytes --]
next prev parent reply other threads:[~2018-01-25 0:09 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-23 0:30 Gregory Maxwell
2018-01-23 1:55 ` Chris Belcher
2018-01-23 2:51 ` Matt Corallo
2018-01-23 14:39 ` Mark Friedenbach
2018-01-23 21:23 ` Matt Corallo
2018-01-23 21:38 ` Gregory Maxwell
2018-01-23 6:44 ` Anthony Towns
2018-01-23 13:15 ` Gregory Maxwell
2018-01-23 22:22 ` Anthony Towns
2018-01-23 22:45 ` Gregory Maxwell
2018-01-24 1:52 ` Andrew Poelstra
2018-01-24 9:28 ` Tim Ruffing
2018-01-24 12:51 ` Natanael
2018-01-24 15:38 ` Tim Ruffing
2018-01-24 18:51 ` Natanael
2018-01-24 23:22 ` Tim Ruffing
2018-01-25 0:09 ` Natanael [this message]
2018-01-26 13:14 ` [bitcoin-dev] Recovery of old UTXOs in a post-quantum world Tim Ruffing
2018-01-27 17:07 ` [bitcoin-dev] Taproot: Privacy preserving switchable scripting Russell O'Connor
2018-01-27 17:23 ` Matt Corallo
2018-01-23 15:43 ` Greg Sanders
2018-01-26 21:34 ` Gregory Maxwell
2018-07-13 1:51 ` [bitcoin-dev] Generalised taproot Anthony Towns
2018-10-24 2:22 ` Pieter Wuille
2018-02-05 9:27 ` [bitcoin-dev] Taproot: Privacy preserving switchable scripting ZmnSCPxj
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=CAAt2M19UObuaaODHXb+iW9bWMj53wGHAdjVzZgWBi-ZCCUi4Mg@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