From: Gavin Andresen <gavinandresen@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] From the forums: one-confirmation attack
Date: Thu, 18 Aug 2011 10:00:01 -0400 [thread overview]
Message-ID: <CABsx9T0AgUL+rphhB8YUVHDGJnc0TmaYG=kjt7Pz1yrwLjBbDQ@mail.gmail.com> (raw)
vector76 on the Forums posted this interesting variation on a 'Finney attack' :
https://bitcointalk.org/index.php?topic=36788.msg463391#msg463391
"Let's say I observe the timing of when nodes are broadcasting
transactions and how they are propagating through the network. By
watching for which nodes are earliest to broadcast transactions from
my target, I manage to establish a direct connection to my target.
I use a similar method of watching block broadcasts to establish
connections to most of the mining pools.
Now I create a transaction making a valid, large deposit into my
target. I do not broadcast this transaction but I add it to a block
that I am attempting to mine. I mine solo, just like normal, except
that I have an extra non-broadcasted tx that I am including.
Eventually, I succeed in creating a valid block. I do not broadcast
it immediately, but instead I wait until someone else mines a block,
and when that happens, I immediately broadcast my block to my target.
If my target sees my block before the other block, they will accept
it, and my transaction will have one confirmation. The block chain
has forked, and my target (and possibly other nodes, if my target
relays quickly enough) will believe that my block is the correct one,
while other nodes will believe that the other fork is the correct one.
I immediately request a withdrawal, and my target generates a
transaction sending the large amount of coins to an address I control.
I also double-spend some of the inputs, sending the coins to myself.
The part of the network that did not receive my block first (which
hopefully is most of the miners) will accept this as valid and work to
include it in the next block.
If my block eventually "wins" because enough miners saw my block first
and added onto it first, then I have just made a deposit and
withdrawal, and I lose nothing.
If my block eventually "loses", then the deposit is invalidated. If
the deposit tx was not one of the inputs to the withdrawal
transaction, then the withdrawal is still valid."
-------------------------------
The lessons are "don't accept 1-confirmation transactions" and "try
to be well-connected."
But maybe the deeper lesson is "don't trust information you get from
only one peer." Or maybe "watch for peers that are trying to fool
you."
--
--
Gavin Andresen
next reply other threads:[~2011-08-18 14:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-18 14:00 Gavin Andresen [this message]
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
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='CABsx9T0AgUL+rphhB8YUVHDGJnc0TmaYG=kjt7Pz1yrwLjBbDQ@mail.gmail.com' \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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