public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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 [Bitcoin-development] Coinbase reallocation to discourage Finney attacks 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.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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