From: Mike Hearn <mike@plan99•net>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Date: Wed, 23 Apr 2014 21:19:24 +0200 [thread overview]
Message-ID: <CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3380 bytes --]
On Wed, Apr 23, 2014 at 8:57 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> Hm? I didn't think this is at all what they did. What they claim to
> do is to prioritize transactions in their mempool from people who pay
> them
>
That's the definition of a Finney attack, right? A tx is broadcast and
nodes normally take the first one they saw, allowing you to measure
propagation and use double spend alerts to get pretty good confidence,
pretty quick. A Finney attacker doesn't do that and includes a double
spend, so the one in the mempool gets overridden.
I mean, I hope that's the definition of a Finney attack, given that I
coined the term :)
> I think we have very clear evidence that the Bitcoin community doesn't
> care if miners reorder transactions in their mempool to profitable
> ends: In https://bitcointalk.org/index.php?topic=327767.0 it's
> demonstrated that GHash.IO, currently the largest publicly identified
> pool was used to rip off Betcoin dice via double-spends.
>
Yes, very disappointing. Though I'd hope that if this sort of thing was
sustained over months and merchants started dropping Bitcoin as a result,
miners would pay more attention.
Right now I suspect miners don't pay attention to anything other than
hardware builds though.
Yes, Bitcoin is imperfect at stopping double spends today. It can certainly
be improved! There are plenty of oft-discussed measures like double spend
alerts and discouraging Finney-attack blocks as was debated extensively in
2011. This thread is just a third such proposal.
More importantly, it's possible to deploy technological approaches to
> make zero-conf very secure against reversal: Things like performing
> multi-sig with a anti-double-spending system
>
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.
That may well be how the Bitcoin experiment ends, but I think we all agree
here that block chains and decentralised consensus are quite spiffy and we
should try hard to make them work as well as possible before just shrugging
and say "find a trusted third party". Otherwise why not just go back to
using MasterCard? Any TTP that enforces anti double spending rules will be
a lot more centralised than miners, given the difficulty of finding them,
their need for a strong brand/reputation, and the difficulty of getting
everyone to agree on them.
Not to mention that this solution makes Bitcoin sound like a joke currency.
It's a super duper low fee totally decentralised financial system .....
unless you want to buy something in, you know, a shop. And walk out. Then
you need to sign up with this company that looks suspiciously like a bank,
and pay their fees, and yeah there's like 3 to pick from. Totally
decentralised!
> 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.
So I think the ability to resell double spending to lots of different
people around the world seems important to practicality.
[-- Attachment #2: Type: text/html, Size: 4523 bytes --]
next prev parent reply other threads:[~2014-04-23 19:19 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
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 [this message]
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='CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/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