public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Date: Wed, 23 Apr 2014 13:24:09 -0700	[thread overview]
Message-ID: <CAAS2fgR1dRFVqhTNn55dZ6FS5zDM0aHs4ROPSD37hWwzLUKfCg@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP0fUhiFeH4A1Y9sLCORpggJs3dxHz+exgpKaLQe9rgFeA@mail.gmail.com>

On Wed, Apr 23, 2014 at 12:59 PM, Mike Hearn <mike@plan99.net> wrote:
>> What you're talking about is just disagreement about the content of
>> the memory pool
> That's the same thing. Whilst you're mining your double spend tx, it's in
> your mempool but you don't broadcast it as per normal. Then when you find
> the block you broadcast it to override everyone elses mempool. So yours and
> theirs were inconsistent.

The difference is when you transact.  In the attack Hal described you
transact with your victim only after finding a block but before
announcing it.

> don't know if they inform you when they found a block (probably not), so you
> have to do the purchase and then hope BitUndo finds the next block.

Right, this works in the Bitcoin network today absent any collusion by
the miners. You give one miner a transaction and you give every other
node you can reach another transaction.  You then hope your selected
miner finds the next block and 'undoes' the transaction you gave the
rest of the network.

> This just brings us back to square one. Who are these parties and what if I
> pay them to be corrupt? What if they offer to be corrupt as a service?
>
> Let's say I succeed in finding some parties who are incorruptible no matter
> how large of a percentage I offer them. At this point, why bother with
> miners at all? Why pay for double spend protection twice, once to a group of
> Oscar's who are trustworthy and once to a group of miners who are not?
>
> The point of the broadcast network and mining is so there can be lots of
> Oscar's and I don't have to know who they are or sign up with them or put
> any effort into evaluating their reputation.

But it isn't at all the same thing.  Miners select themselves based on
controlling hash-power. You can distrust a miner all you like but all
your distrust does not prevent him from participating in the
consensus, potentially to your detriment.  Moreover, the set of miners
has to be the same for everyone or otherwise the network doesn't
converge. There are miners I _know_ to be scoundrels, but there is
nothing I can do about it.

Someone you ask to not double spend is an entirely separate matter.
They aren't self-selecting: you select who you trust to not make
double spends and there is no need for this trust to be globally
consistent. If they behave in an untrustworthy way you can instantly
stop honoring them because the bad action is provable beyond any doubt
and never trust them again (unlike mempool consistency)... and you can
do this even if everyone else is too foolish to do so for some reason.

The trustworthness of oscars needs only be limited and is different in
kind from the kind of 'trust' we need over the history— they
arbitrating over the ordering of some subset of transactions right at
the tip of the chain, and only those transaction of people who have
specifically chosen to use them, of lower value transactions where you
need instant settlement.  Why pay twice? Because you're actually
getting a different part of your security from each, and the result is
additive.

There is no such thing as an uncorruptable party, invoking that is a
useless strawman. Instead we can consider how difficult the corruption
is and what can happen if they're corrupted and hope to balance the
risks and the controls for those risks.  Any self-selectingness as
anonymity (in the not-previously-enumerated sense) of mining is
important for censorship security but it's terrible for other things
like getting reliable mempool behavior.

> But as you point out, cheating my GHash.io did not result in any obvious
> negative consequence to them, despite that preventing double spending is
> their sole task. Why would Oscar be different to GHash.io?

Because you can choose to stop trusting an oscar while you—
individually— can't choose anything about ghash.io.  To stop GHash.io
we would have to take away their hardware or change the Bitcoin
protocol to make their hardware useless, and in the latter case we'd
_all_ have to agree to do this not just some (perhaps quite large)
subset of us who doesn't want to trust them, and even though it is
quite apparent what they did there is still some room to claim doubt.

> Trying to solve the problem of dishonest miners is effectively trying to
> solve the "automatically find trusted third parties" problem at scale.

Mining is universal— everyone must use the same miners, trust seldom
is seldom universal and shouldn't be. The trust we have in mining is
exceptionally limited, I think any effort to increase it is doomed to
fail— both because trust heavy systems stink, because mining is a bad
fit for trust, and because increasing the requirements create other
exposures and vulnerabilities.



  reply	other threads:[~2014-04-23 20:24 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
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 [this message]
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=CAAS2fgR1dRFVqhTNn55dZ6FS5zDM0aHs4ROPSD37hWwzLUKfCg@mail.gmail.com \
    --to=gmaxwell@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.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