Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.173 as permitted sender)
	client-ip=209.85.213.173; envelope-from=gmaxwell@gmail.com;
	helo=mail-ig0-f173.google.com; 
MIME-Version: 1.0
In-Reply-To: <5431CD8D.7050508@certimix.com>
References: <5431CD8D.7050508@certimix.com>
Date: Sun, 5 Oct 2014 16:40:43 -0700
Message-ID: <CAAS2fgQ-MrmBGjcuqYdvfs0g2b6+vAOVR3sUCCyQy386CY8EDA@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:00 PM, Sergio Lerner <sergiolerner@certimix.com> wrote:
> I would like to share with you a vulnerability in the Bitcoin protocol I've
> been thinking of which might have impact on the future of Bitcoin. Please
> criticize it!
> The Freeze on Transaction Problem

I should point you to some of the tools that have been discussed in
the past which are potentially helpful here:

The first is the use of locktime on normal transactions.  This
behavior is already in Bitcoin core git:   The idea is that users of
the system should locktime their transaction at a point as high as
they expect it to get included.  If used well this means that there
should always be a base of fees which can only be collected by future
blocks, creating an incentive to move forward.  This may be
particularly effective if the limitations on blocksize mean that there
is always a healthy standing load.

The second is having block commitments in transactions
(https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas). The idea is that
the data under signature in a transaction could commit to some recent
block which _must_ be in the chain or the transaction's fee cannot be
collected (or, at least, not all of the fee).  This would allow
transacting users to 'vote with their fees' on the honest chain.
Arguably this could also be used to pay for doublespending forks, but
you can already do that by paying fees via a chain that stems from the
doublespend.  This greatly complicates strategy for forking miners,
since future transactions which you haven't even seen yet may have
fees conditional on the honest chain.

I think both of the above are obviously useful, should be done, but
don't completely address the concern, they may be adequate.

The third is fee forwarding.  An example form would be that the miner
gets half the fees, the rest are added to a pool which pays out half
in every successive block.  This can prevent unusually high fees from
making as much reorg pressure and more correctly models what people
would like to pay for: getting their txn buried.   The huge problem
with this class is that miners can demand users pay fees "out of
band", e.g. with additional txouts (just make a different version of
the tx for each miner you wish to pay) and escape the process.  I have
had some notions about fees that come in the form of adjusting the
difficulty of creating a block slightly (which is something that can't
be paid out of band), but such schemes becomes very complicated very
fast.  I am unsure if any form of fee forwarding is workable.

Something you might want to try to formalize in your analysis is the
proportion of the network which is "rational" vs
"honest"/"altruistic".  Intuitively, if there is a significant amount
of honest hashrate which is refusing to aid the greedy behavior even
at a potential loss to themselves this strategy becomes a loser even
for the purely greedy participants. It would be interesting to
characterize the income tradeoffs for different amounts of altruism,
or whatever convergence problems an attempt by altruistic
participaints to punish the forkers might create.