Message-ID: <53581584.307@certimix.com>
Date: Wed, 23 Apr 2014 16:33:24 -0300
From: Sergio Lerner <sergiolerner@certimix.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: bitcoin-development <bitcoin-development@lists.sourceforge.net>
References: <20140423152954.GG19430@savin>
In-Reply-To: <20140423152954.GG19430@savin>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: bitcoin-research@lists.cs.princeton.edu
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
 Finney attacks]
Precedence: list

(this e-mail is cc to the bitcoin-research list)

Hi everyone from the bitcoin-development mailing list!
I decided to join this legendary list because it seems that all the
research fun is taking place in here, and I don't want to miss the
research party.

Regarding the discussion about BitUndo, a year ago I posted about an
attack (which I called the the Bitcoin Eternal Choice for the Dark Side
Attack or ECDSA)
that tries to erode the confidence in Bitcoin by offering double-spends
as a service.

I think it's related to the last post from Peter Todd about the problems
with BitUndo.

Here is the link if anyone is interested in reading about it...
http://bitslog.wordpress.com/2013/06/26/the-bitcoin-eternal-choice-for-the-dark-side-attack-ecdsa/

Sergio D. Lerner.


On 23/04/2014 12:29 p.m., Peter Todd wrote:
> Interesting discussion re: incentive compatibility happening on the
> bitcoin-development email list:
>
> ----- Forwarded message from Mike Hearn <mike@plan99.net> -----
>
> Date: Wed, 23 Apr 2014 09:55:30 +0200
> From: Mike Hearn <mike@plan99.net>
> To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
> Subject: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
>
> Lately someone launched Finney attacks as a service (BitUndo). As a
> reminder for newcomers, Finney attacks are where a miner secretly works on
> a block containing a double spend. When they eventually find a block, they
> run to the merchant and pay, then broadcast the block. In a simpler variant
> of this attack you make purchases as normal with a modified wallet that
> always submits a double spend to the service, and then N% of the time where
> N is the percentage of overall hash power the dishonest miners have, you
> get your money back minus their fee.
>
> N does not need to be very high to render Bitcoin much less useful. Real
> time transactions are very important. Although I never expected it when I
> first started using Bitcoin, nowadays most of my purchases with it are for
> food and drink. If Bitcoin could not support such purchases, I would use it
> much less.
> Even with their woeful security many merchants see <1-2% credit card
> chargeback rates, and chargebacks can be disputed. In fact merchants win
> about 40% of chargeback disputes. So if N was only, say, 5%, and there was
> a large enough population of users who were systematically trying to
> defraud merchants, we'd already be having worse security than magstripe
> credit cards. EMV transactions have loss rates in the noise, so for
> merchants who take those Bitcoin would be dramatically less secure.
>
> The idea of discouraging blocks that perform Finney attacks by having
> honest miners refuse to build on them has been proposed. But it has a
> couple of problems:
>
>    1. It's hard to automatically detect Finney attacks. Looking for blocks
>    that contain unseen transactions that override the mempool doesn't work -
>    the dishonest users could broadcast all their double spends once a Finney
>    block was found and then broadcast the block immediately afterwards, thus
>    making the block look like any other would in the presence of double spends.
>
>    2. If they could be automatically identified, it possibly could be
>    converted into a DoS on the network by broadcasting double spends in such a
>    way that the system races, and every miner produces a block that looks like
>    a Finney attack to some of the others. The chain would stop advancing.
>
>    3. Miners who want to vote "no" on a block take a big risk, they could
>    be on the losing side of the fork and end up wasting their work.
>
> We can resolve these problems with a couple of tweaks:
>
>    1. Dishonest blocks can be identified out of band, by having honest
>    miners submit double spends against themselves to the service anonymously
>    using a separate tool. When their own double spend appears they know the
>    block is bad.
>
>    2. Miners can vote to reallocate the coinbase value of bad blocks before
>    they mature. If a majority of blocks leading up to maturity vote for
>    reallocation, the value goes into a pot that subsequent blocks are allowed
>    to claim for themselves. Thus there is no risk to voting "no" on a block,
>    the work done by the Finney attacker is not wasted, and users do not have
>    to suffer through huge reorgs.
>
> This may seem a radical suggestion, but I think it's much less radical than
> some of the others being thrown around.
>
> The above approach works as long as the majority of hashpower is honest,
> defined to mean, working to stop double spending. This is the same security
> property as described in the white paper, thus this introduces no new
> security assumptions. Note that assuming *all* miners are dishonest and are
> willing to double spend automatically resolves the Bitcoin experiment as a
> failure, because that would invalidate the entire theory upon which the
> system is built. That doesn't mean the assumption is wrong! It may be that
> an entirely unregulated market for double spending prevention cannot work
> and the participants eventually all end up trashing the commons - but the
> hope is that smart incentives can replace the traditional reliance on law
> and regulation to avoid this.
>
> The voting mechanism would only apply to coinbases, not arbitrary
> transactions, thus it cannot be used to steal arbitrary users bitcoins. A
> majority of miners can already reallocate coinbases by forking them out,
> but this wastes energy and work presenting a significant discouragement to
> vote unless you already know via some out of band mechanism that you have a
> solid majority. Placing votes into the coinbase scriptSig as is done with
> other things avoids that problem.
>
> The identification of Finney blocks relies on miners to take explicit
> action, like downloading and running a tool that submits votes via RPC. It
> can be expected that double spending services would try to identify and
> block the sentinel transactions, which is why it's better to have the code
> that fights this arms race be out of process and developed externally to
> Bitcoin Core itself, which should ultimately just enforce the new (forking)
> rule change.
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ----- End forwarded message -----