Bitcoin Forum
November 05, 2024, 12:33:46 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Double-spending with 6 confirmations  (Read 2850 times)
Xenland
Legendary
*
Offline Offline

Activity: 980
Merit: 1003


I'm not just any shaman, I'm a Sha256man


View Profile
October 08, 2012, 09:59:07 PM
 #21

If your so worried about this issue, I would recommend running 8 Bitocin nodes in different servers around the world and have only your clients connect to those 8 Bitcoin nodes ONLY and not the hardcoded IP addresses in Bitcoin, It would be impossible for anyone to find out all those 8 server(Unless you told them which your an idiot if that became the ase). This way you surround your self with "Clean" nodes and only if all 8 Bitcoin nodes were cancerous would your Clients turn cancerous which is infeasible.
Come-from-Beyond (OP)
Legendary
*
Offline Offline

Activity: 2142
Merit: 1010

Newbie


View Profile
October 08, 2012, 10:07:26 PM
 #22

If your so worried about this issue, I would recommend running 8 Bitocin nodes in different servers around the world and have only your clients connect to those 8 Bitcoin nodes ONLY and not the hardcoded IP addresses in Bitcoin, It would be impossible for anyone to find out all those 8 server(Unless you told them which your an idiot if that became the ase). This way you surround your self with "Clean" nodes and only if all 8 Bitcoin nodes were cancerous would your Clients turn cancerous which is infeasible.

I need a solution for everyone, not only for myself. But thx anyway.
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
October 08, 2012, 10:17:46 PM
Last edit: October 08, 2012, 10:35:22 PM by DeathAndTaxes
 #23

I need a solution for everyone, not only for myself. But thx anyway.

One option would be have the client allow users to set a trusted node.   For example if a user trusted his friend, blockchain.info, his mining pool, or MtGox he could set that as a trusted node and it would always attempt that connection first.  Currently that can be done from the config but an easy to use GUI would be a method to improve security.

A more robust solution would be an (optional) system where nodes were strongly authenticated using a public/private key type system.  This would also prevent MITM type attacks where attacker intercepts communication from "good nodes" and relays false data to victim.   Say you trust me and you have my public key.  When you bootstrap you could request the nodes that you connect to to search for my node and relay that.  An attacker couldn't impersonate my node without my private key.  An attacker could still prevent communication however you client could alert you (or even be programmed to not accept any data which doesn't come from at least one trusted node).

Taking it a step further a WOT type system could be put in place.  I trust come-from-behind so I mark his node as trusted (digitally signed w/ my private key).   A new node comes online and it doesn't trust cfb but it does trust me.  Even if my node if offline the indirect trust could be used for the node to connect to cfb in a semi-trusted manner.

Come-from-Beyond (OP)
Legendary
*
Offline Offline

Activity: 2142
Merit: 1010

Newbie


View Profile
October 08, 2012, 10:30:04 PM
 #24

Seems to be a good idea. I'll think about it.
Xenland
Legendary
*
Offline Offline

Activity: 980
Merit: 1003


I'm not just any shaman, I'm a Sha256man


View Profile
October 08, 2012, 10:33:36 PM
 #25

If your so worried about this issue, I would recommend running 8 Bitocin nodes in different servers around the world and have only your clients connect to those 8 Bitcoin nodes ONLY and not the hardcoded IP addresses in Bitcoin, It would be impossible for anyone to find out all those 8 server(Unless you told them which your an idiot if that became the ase). This way you surround your self with "Clean" nodes and only if all 8 Bitcoin nodes were cancerous would your Clients turn cancerous which is infeasible.

I need a solution for everyone, not only for myself. But thx anyway.

Well then host 1000 Clean bitcoin nodes or at least host more Bitcoin nodes around the world more than cancer nodes.  Did anyone mention to you that its near impossible to know if you've taken over a Bitcoin client(Unless you have some kind of control over the computer it self to query the Bitcoin client for the connected nodes)? I was gritty about this issue my self a year back, The only answer is that its very infeasible for this to happen unless the incentive is great (You know your friend has a million bitcoins and leaves his computer open) but I'd imagine when Bitcoin goes mainstream more then half the population will not know how, or even want to run their own Bitcoin nodes to leave their own computer security to their self and bitting their teeth all day wondering if their Bitcoins are stolen yet or if they "Did it right", they will rely on companies called Bitcoin banks or a hardware device that thwarts these kind of attacks).
Serith
Sr. Member
****
Offline Offline

Activity: 269
Merit: 250


View Profile
October 09, 2012, 08:08:14 PM
 #26

This idea came after reading https://bitcointalk.org/index.php?topic=114102.00:

Imagine that someone opened a lot of connections with multiple IPs to other nodes. Number of such connections so big that there are a lot of nodes connected only to the attacker. Let's assume the attacker attempts double-spending attack with the following scenario:

1. He chooses a victim and says that he will pay some bitcoins for something.
2. The attacker sends a transaction only to the victim, all other nodes know nothing about the transaction.
3. The attacker solves 6 blocks so the transaction gets 6 confirmations.
4. The victim sees the confirmations and complete its part of the deal.
5. While the attaker was solving his blocks the main blockchain got higher cumulative difficulty coz more than 6 blocks were solved. Even if the victim reconnects to other nodes it will see that non-legit transaction disappeared from the blockchain and the attacker still owns "spent" coins.

Is it possible theoretically and practically? What could be used to prevent such an attack?

This is very simular to a speculation of how MyBitcoin, which required only 1 confirmation, was hacked with only 1 pre-mined block instead of 2 as required for a normal withholding attack: White Paper, section 11


You don't need to mine 2 blocks in a row.  Mining a single block is sufficient if the network resolves the fork the way you want, and it might be possible to set things up so that this is likely.

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.


+1 for vector76's hypothesis.

If mybitcoin was running bitcoin behind Tor, and had just one connection (through a Tor exit node) to the rest of the bitcoin network, then they'd be particularly susceptible to this 1-confirmation attack.


Realpra
Hero Member
*****
Offline Offline

Activity: 815
Merit: 1000


View Profile
October 09, 2012, 08:26:18 PM
 #27

If the victim broadcasts tx then only the attacker receives it.
That's an isolation attack, its pretty well known, but rather hard to execute.

Additionally you would likely only be able to scam small merchants for small amounts for all your effort.

I'm not worried about this at all.

Cheap and sexy Bitcoin card/hardware wallet, buy here:
http://BlochsTech.com
Syke
Legendary
*
Offline Offline

Activity: 3878
Merit: 1193


View Profile
October 10, 2012, 09:05:37 AM
 #28

3. The attacker solves 6 blocks so the transaction gets 6 confirmations.
...
Is it possible theoretically and practically? What could be used to prevent such an attack?

Let's say the attacker has a decent 10 GH/s farm. It would only take him 3 months on average to solve 6 blocks. Doesn't sound practical to me.

Buy & Hold
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1026



View Profile
October 10, 2012, 12:34:13 PM
 #29

3. The attacker solves 6 blocks so the transaction gets 6 confirmations.
...
Is it possible theoretically and practically? What could be used to prevent such an attack?

Let's say the attacker has a decent 10 GH/s farm. It would only take him 3 months on average to solve 6 blocks. Doesn't sound practical to me.

The 6 blocks need to be consecutive and current, not random.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4270
Merit: 8805



View Profile WWW
October 10, 2012, 02:15:59 PM
 #30

This is very simular to a speculation of how MyBitcoin, which required only 1 confirmation, was hacked with only 1 pre-mined block instead of 2 as required for a normal withholding attack: White Paper, section 11
As an aside, many people searched and none could find an orphaned block in their storage (bitcoin stores all blocks lost in reorgs) which contained a double spend against the main chain, making their claimed attack vector very unlikely. Moreover they refused to provide a copy of their blockchain file, which would have conclusively proved the attack. In light of this I believe it's far more likely that they gambled away or just outright stole the funds.

In any case, Bitcoin "takes advantage of the nature of information being easy to spread but hard to stifle"— you only need one honest connection to resist this kind of attack, and the attack can't be performed against reasonable client software that enforces a reasonable number of confirmations without a considerable cost in producing doomed blocks.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!