From: Gregory Maxwell <gmaxwell@gmail•com>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] From the forums: one-confirmation attack
Date: Thu, 18 Aug 2011 12:46:17 -0400 [thread overview]
Message-ID: <CAAS2fgQJZ2b-YDZKfmbA-rTtZfmKsP=QBYuYSQbwFdihoQyHsQ@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T2zpG=M6nkX4W=KrAJAYaTFR25_MLFmwj43+btWanqqsw@mail.gmail.com>
On Thu, Aug 18, 2011 at 12:16 PM, Gavin Andresen
<gavinandresen@gmail•com> wrote:
> We could start with an as simple-as-possible "confidence == 0 if
> confirmations < 2, otherwise confidence = function(#confirmations)"
> and improve it from there.
At the same time, if this causes people to wait less than the 6 blocks
that the software currently waits for before leaving unconfirmed
status then that would be sad.
Simply waiting a number of blocks is an excellent metric and provides
robustness against almost all attack patterns in a way that various
one-off-heuristics can not as it equates to _real difficulty_ (and
real expense (hashing computation, loss of income on the orphaned
blocks)) in a way that can't be faked.
A few weeks back when there was some rumor going around that mybitcoin
lost coin based on some kind of one confirmation attack I described on
IRC a similar attack pattern which had a useful improvement:
* The attacker runs many widely distributed sybil nodes (e.g. using
botnet drones as simple tcp proxies to appear at many addresses). He
takes advantage of the fact the bitcoin won't connect to /16s that
have already connected to it to further isolate nodes.
* By creating normal looking probe transactions which his own nodes
won't forward he detects network partitions which he is able to
create. He searches for a cut which causes there to be at least two
partitions which contain significant mining power.
* He creates two accounts at MoronBank. He doesn't even bother
identifying MoronBank's node. MoronBank will be in one partition or
another. He makes deposits in both partitions, and conflicting
transactions in the opposite partitions, while carefully filtering out
these transactions from crossing the boundary.
(Notably, the network doesn't appear partitioned to everyone else now
because he's still forwarding blocks and transactions unrelated to his
attack— it only becomes visible once some of his evil transactions are
mined)
* After the funds show up in MoronBank he withdraws and drops the partitioning.
Only if he has difficulty getting MoronBank into the smaller partition
does he need to bother locating it and attacking it directly.
The bad thing about this attack is that it doesn't require the
attacker to have any hash power at all: he captures miners as
unwilling (or willing but plausibly deniable) participants. The lost
income from orphaned blocks is externalized to the victimized miners
(and since most pools don't pay orphaned blocks out of pocket a pool
operator would be inclined to help out).
The good thing about it is that it's killed dead by nodes adding in a
few manually configured peerings, they don't even really need to be
trusted: You just need to trust that they don't all go to a single
bad-guy conspiracy. At a minimum all major miners should be fully
meshed.
Unfortunately, We don't currently have software for this as addnode
doesn't worry about keeping the links up... and the major pools also
don't seem to be interested in participating.
next prev parent reply other threads:[~2011-08-18 16:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-18 14:00 Gavin Andresen
2011-08-18 15:36 ` Joel Joonatan Kaartinen
2011-08-18 15:52 ` Mike Hearn
2011-08-18 16:16 ` Gavin Andresen
2011-08-18 16:46 ` Gregory Maxwell [this message]
2011-08-18 17:36 ` Gavin Andresen
2011-08-18 16:47 ` theymos
2011-08-18 17:27 ` Gregory Maxwell
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='CAAS2fgQJZ2b-YDZKfmbA-rTtZfmKsP=QBYuYSQbwFdihoQyHsQ@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@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