From: Kevin <kevinsisco61784@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Date: Wed, 23 Apr 2014 11:34:39 -0400 [thread overview]
Message-ID: <5357DD8F.6050308@gmail.com> (raw)
In-Reply-To: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5936 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 8155 bytes --]
next prev parent reply other threads:[~2014-04-23 15:34 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-23 7:55 Mike Hearn
2014-04-23 9:57 ` Andy Parkins
2014-04-23 11:07 ` Mike Hearn
2014-04-23 11:39 ` Andy Parkins
2014-04-23 11:45 ` Mike Hearn
2014-04-23 13:21 ` Andy Parkins
2014-04-23 13:31 ` Mike Hearn
2014-04-24 9:21 ` Andy Parkins
2014-04-23 12:43 ` Christophe Biocca
2014-04-23 12:51 ` Mike Hearn
2014-04-23 14:52 ` Justus Ranvier
2014-04-23 15:07 ` Mike Hearn
2014-04-23 17:19 ` Justus Ranvier
2014-04-23 17:47 ` Gavin Andresen
2014-04-23 17:49 ` Justus Ranvier
2014-04-23 17:57 ` Mike Hearn
2014-04-23 18:04 ` Justus Ranvier
2014-04-23 18:15 ` Peter Todd
2014-04-23 18:20 ` Justus Ranvier
2014-04-23 18:37 ` Mike Hearn
2014-04-23 18:49 ` Justus Ranvier
2014-04-23 19:01 ` Drak
2014-04-23 18:58 ` Tier Nolan
2014-04-23 15:04 ` Alex Mizrahi
2014-04-23 15:09 ` Mike Hearn
2014-04-23 15:38 ` Alex Mizrahi
2014-04-23 16:04 ` Christophe Biocca
2014-04-23 16:19 ` Chris Pacia
2014-04-23 16:21 ` Mike Hearn
2014-04-23 16:33 ` Kevin
2014-04-24 11:22 ` Jorge Timón
2014-04-24 11:43 ` Mike Hearn
2014-04-24 13:57 ` Jorge Timón
2014-04-24 14:28 ` Mike Hearn
2014-04-24 15:37 ` Jorge Timón
2014-04-24 17:07 ` Justus Ranvier
2014-04-25 4:31 ` Gareth Williams
2014-04-25 10:17 ` Mike Hearn
2014-04-25 13:19 ` Gareth Williams
2014-04-25 15:28 ` Mike Hearn
2014-04-26 12:15 ` Gareth Williams
2014-04-27 1:42 ` Christophe Biocca
2014-04-27 12:53 ` Gareth Williams
2014-04-27 14:31 ` Mike Hearn
2014-04-27 23:10 ` Gareth Williams
2014-04-28 21:41 ` Adam Back
2014-04-29 14:13 ` Mike Hearn
2014-04-29 14:21 ` Gregory Maxwell
2014-04-29 14:26 ` Mike Hearn
2014-04-30 13:12 ` Gareth Williams
2014-04-30 13:55 ` Mike Hearn
2014-04-30 14:31 ` Gareth Williams
2014-04-29 19:29 ` Justus Ranvier
2014-04-30 13:00 ` Gareth Williams
2014-04-30 17:06 ` Troy Benjegerdes
2014-04-30 17:13 ` Jameson Lopp
2014-04-30 14:08 ` Gareth Williams
2014-04-23 15:28 ` Peter Todd
2014-04-23 15:34 ` Kevin [this message]
2014-04-23 15:41 ` Pieter Wuille
2014-04-23 15:55 ` Peter Todd
2014-04-23 18:57 ` Gregory Maxwell
2014-04-23 19:19 ` Mike Hearn
2014-04-23 19:47 ` Gregory Maxwell
2014-04-23 19:59 ` Mike Hearn
2014-04-23 20:24 ` Gregory Maxwell
2014-04-23 20:37 ` Mike Hearn
2014-04-23 20:44 ` Adam Ritter
2014-04-23 20:51 ` Mike Hearn
2014-04-24 15:13 ` Sergio Lerner
2014-04-24 15:34 ` Mike Hearn
2014-04-23 20:53 ` Gregory Maxwell
2014-04-23 21:23 ` Tier Nolan
2014-04-23 21:39 ` Gregory Maxwell
2014-04-23 22:26 ` Tier Nolan
2014-04-24 0:55 ` Tom Harding
[not found] ` <CAKuKjyWDniyP503XSw8=tK9XQW-T58j+VD6ajXCxz=HihN93mQ@mail.gmail.com>
2014-04-24 14:52 ` [Bitcoin-development] Fwd: " Adam Ritter
2014-04-23 20:41 ` [Bitcoin-development] " Daniel Krawisz
2014-04-23 22:06 ` Alex Mizrahi
2014-04-24 7:58 ` Mike Hearn
2014-04-24 8:19 ` Gregory Maxwell
2014-04-24 8:39 ` Mike Hearn
2014-04-24 9:25 ` Gregory Maxwell
2014-04-24 9:56 ` Mike Hearn
2014-04-24 13:44 ` Peter Todd
2014-04-24 14:09 ` Mike Hearn
2014-04-24 14:47 ` Christophe Biocca
2014-04-24 15:03 ` Peter Todd
2014-04-24 16:05 ` Christophe Biocca
2014-04-24 16:14 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5357DD8F.6050308@gmail.com \
--to=kevinsisco61784@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox