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 12:47:46 -0700	[thread overview]
Message-ID: <CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>

On Wed, Apr 23, 2014 at 12:19 PM, Mike Hearn <mike@plan99.net> wrote:
> That's the definition of a Finney attack, right?

A finney attack is where you attempt to mine a block with a
transaction paying you, and as soon as you are successful you quickly
make a transaction spending that coin to someone else, then release
the block after they've taken an irreversible action. If everything is
automated it should have something like a 99% success rate, though it
has a cost of some small increase in the number of orphan blocks you
experience.

> I mean, I hope that's the definition of a Finney attack, given that I coined
> the term :)

You might have coined the term, but I don't think the attack you're
describing is the attack Hal described:
https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384

What you're talking about is just disagreement about the content of
the memory pool, but we have no consensus mechanism there (the
blockchain _is_ the consensus mechanism).  Mempools are sometimes
inconsistent all on their own, without any attacker being involved.

> These sorts of proposals are all just ways of saying block chains kind of
> suck and we should go back to using trusted third parties.

I think thats an unsophisticated view.

Consider this protocol.

I take some of my funds and assign them to a 2 of 2 multisig with
myself and Oscar. I do not announce this transaction until I get Oscar
to sign a timelocked anyonecanpay refund to send the coin back to me
(say in 3 months).  Oscar gives me my refund and I announce the
transaction.

Later I can make instant payments with oscar signing up until the
refund time comes clue to anyone who trusts Oscar to never double
spend.  For the receiver this is purely additive with regular
blockchain security: in that even with Oscar's help I cannot double
spend except where I would have been successful absent Oscar. On the
sender side, Oscar cannot up and steal my funds and he can't try to
extort me (except by creating a delay up to the refund time).

Oscar himself can be implemented as a majority M parties to further
increase confidence, though if you're talking about using this for low
value retail transactions— the fact that any cheating by oscar is
cryptographically provable (just show them the double signatures)
maybe be strong enough alone. (Though there is a multitude of other
proposals to provide more evidence of Oscar's honesty). There are also
ways to blind Oscar so he can't reliably identify which transactions
are ones he signed for.

I don't think this is at all a "return to trusted third parties"— that
it's a shrug and an admission of defeat. Its a very narrowly scoped
trust, filling in precisely where large scale decentralized consensus
is fundamentally weak... the result is something which combines
advantages from both classes and is stronger than either trust or
blockchains alone.  (I'm also not trying to say that an implementation
of this is _simple_ by any means, working out all the details is
hard.)

By contrast, I think proposals which overly depend on colluding miners
to behave in very specific ways are themselves just a way of saying
block chains suck unless we turn the miners themselves into a trusted
third party. I'm much more in favor of adding a little bit of
mastercard to transactions where mastercard is really what people
want, than turning mining— and thus bitcoin itself— into mastercard,
especially since miners— self selecting as they are— are a pretty poor
set of parties to act as trusted agents. :)

>> Doubly so because a 'nasty' party with non-trivial hash-power can
>> doublespend their own transactions
> If a miner is vertically integrated and defrauding merchants themselves,
> with no service component, pretty quickly people would talk to each other,
> notice this pattern and stop trading with them, making their coins rather
> useless. Also if their real identity is ever revealed they could be liable
> and there'd be a lot of people wanting to sue them.

We have an existence proof that it isn't so— you can say that it
wasn't consistent enough, but what is? There wasn't any major doubt
that they were actually doing it. They're the largest identifiable
pool as we speak.

I think, instead, that strong zero-conf security isn't a part of what
many people think of when they think of Bitcoin's characteristics.
Zero conf is risky, and I think for a lot of people thats okay.  If it
isn't there are ways to improve it that don't involve asking miners to
participate in a majority vote to take away funds from people.



  reply	other threads:[~2014-04-23 19:47 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 [this message]
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=CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@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