On 4/23/2014 3:55 AM, Mike Hearn wrote:
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
I have some questions:
1. How can we work towards solving the double-spending problem?
2. Is it possible to "scan" for double-spending and correct it?
3. Is the network at large not secure enough?
--
Kevin
------------------------------------------------------------------------------
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