Gavin Andresen [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-18 🗒️ Summary of this message: A variation on ...
📅 Original date posted:2011-08-18
🗒️ Summary of this message: A variation on a 'Finney attack' involves observing the timing of nodes broadcasting transactions to establish a direct connection to a target, creating a non-broadcasted transaction, and waiting to broadcast it until a block is mined by someone else. If the target sees the block first, it will accept it, and the block chain will fork. The attacker can then request a withdrawal and double-spend some of the inputs, sending the coins to themselves. The lesson is to not accept 1-confirmation transactions and to be well-connected.
📝 Original message: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
🗒️ Summary of this message: A variation on a 'Finney attack' involves observing the timing of nodes broadcasting transactions to establish a direct connection to a target, creating a non-broadcasted transaction, and waiting to broadcast it until a block is mined by someone else. If the target sees the block first, it will accept it, and the block chain will fork. The attacker can then request a withdrawal and double-spend some of the inputs, sending the coins to themselves. The lesson is to not accept 1-confirmation transactions and to be well-connected.
📝 Original message: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