Message-ID: <1516836125.5969.11.camel@mmci.uni-saarland.de>
From: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Date: Thu, 25 Jan 2018 00:22:05 +0100
In-Reply-To: <CAAt2M19csW3eTW_rrS+8+OuaG18EhqajWgLFotCrcVfSeVmrrQ@mail.gmail.com>
References: <CAAS2fgTXg5kk6TyUM9dS=tf5N0_Z-GKVmzMLwTW1HxUgrqdo+Q@mail.gmail.com>
	<20180123064419.GA1296@erisian.com.au>
	<CAAS2fgSy8qg71M6ZOr=xj=W6y2Jbz8hwygZOUYv-Brkt0JwVaQ@mail.gmail.com>
	<20180123222229.GA3801@erisian.com.au>
	<CAAS2fgTNcCB2mfvCBhC_AhgxX=g8feYguGHN_VPWW0EoOOxMyA@mail.gmail.com>
	<CAAt2M1-oh=_Ro6+Srit0XYburK_abQgJiW0Jx=nmNyeToA2rSA@mail.gmail.com>
	<1516808291.4277.25.camel@mmci.uni-saarland.de>
	<CAAt2M19csW3eTW_rrS+8+OuaG18EhqajWgLFotCrcVfSeVmrrQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting
Precedence: list

On Wed, 2018-01-24 at 19:51 +0100, Natanael wrote:
> 
> That's not the type of attack I'm imagining. Both versions of your
> scheme are essentially equivalent in terms of this attack. 
> 
> Intended steps: 
> 1: You publish a hash commitment. 
> 2: The hash ends up in the blockchain. 
> 3: You publish the transaction itself, and it matches the hash
> commitment. 
> 4: Because it matches, miners includes it. It's now in the
> blockchain. 

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.

By the way: As described here, everybody could do this first step and
flood the blockchain with it. We cannot immediately subtract a fee,
because it's not clear that some transaction will take place at all. So
we need to take the fee from somewhere else or do something else to
prevent spam. But that's entirely different issue...