Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.171 as permitted sender)
	client-ip=209.85.213.171; envelope-from=gmaxwell@gmail.com;
	helo=mail-ig0-f171.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAAS2fgQ-MrmBGjcuqYdvfs0g2b6+vAOVR3sUCCyQy386CY8EDA@mail.gmail.com>
References: <5431CD8D.7050508@certimix.com>
	<CAAS2fgQ-MrmBGjcuqYdvfs0g2b6+vAOVR3sUCCyQy386CY8EDA@mail.gmail.com>
Date: Sun, 5 Oct 2014 16:50:56 -0700
Message-ID: <CAAS2fgTXWznKYCcqAP_+CkaoGikL1sTnvPnf2WGHS=MbYGsw+w@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Sergio Lerner <sergiolerner@certimix.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack
	(FRONT)
Precedence: list

On Sun, Oct 5, 2014 at 4:40 PM, Gregory Maxwell <gmaxwell@gmail.com>
> I should point you to some of the tools that have been discussed in
> the past which are potentially helpful here:

Ah, I should also mention a somewhat more far out approach which helps
here as a side effect:

If transactions were using the BLS short signature scheme (a very
compact EC signature based on pairing cryptography) there is a scheme
so that you securely can aggregate the signatures from multiple
messages into a single signature (also has nice bandwidth properties)
and still verify it. It also works recursively, so aggregates can be
further aggregated.

A consequence of this is that you cannot remove a (set of)
signature(s) from the aggregate without knowing the (set of)
signature(s) by itself.

If the coinbase transaction also contains a signature and if some
non-trivial portion of fee paying users relayed their transaction
privately to miners it,  then other miners would only learn of the
transaction in aggregated form.  Without knowing the transaction by
itself they could not pull it out of a block separately from the
coinbase payment and add it to their own block in a fork.

(In general this provides several anti-censorship properties, since if
someone passed you an aggregate of several transactions you could only
accept or reject them as a group unless you knew the members
separately).

The use in aggregation can be done in a way which is purely additive
(e.g. in addition to regular DSA signatures), so even if the
cryptosystem is broken the only harm would be allowing
disaggregation... but unfortunately the pairing crypto is pretty slow
(verification takes a 0.5ms-ish pairing operation per transaction).