Topic: Bank Fraud, Is it possible? (Read 2048 times)

No, it is not required. Each client will have its own list.

It is already implemented as far as I know, only need to change the default setting

Yeah bounce around new entries in the network. It's not hard.

list of a last seen hosts, 10-1000 entries

I tend to agree, IRC is not the most trustable of protocols for this, and having all clients connect to an IRC server is an accident waiting to happen. Then again, what would be the alternative? Using a central tracker/'trusted node' is also against the bitcoin spirit.

By the way, perhaps it is time to turn off the IRC-kickstart by default. Too much money can already be stolen for an ordinary hack of the IRC server.

Not really.  Just enough for the bank to notice that transactions and blocks being sent to it by all of it's other peers are fake.  A 2 meg per second residential broadband connection would more than suffice.

Just one peer?
That peer need lots of bandwidth to support the bank.

If you are the bank, no.  This attack vector, even if possible, is defeated if the bank has even one peer that is unknown to the attacker or for which the attacker cannot reliably spoof.  An encrypted tunnel to another bitcoin bank would be enough.

Interesting (if I understood well).

Banks could build some sort of "reliable node set" to protect themselves.
Also, connecting through IP-masking networks like Tor wouldn't be a way to protect yourself against such attack?

It's complicated to conduct such attack too, I think... the bank has to keep receiving and sending to the normal network, otherwise they may suspect something is wrong, after complaints from their clients. So the attacker would have to reproduce all transactions from the real network while decreasing the difficulty. During this period they will produce much less blocks (since they have much less computing power) than the true network... that makes it difficult to mimic the transactions, and the bank might realize something is wrong (transactions get too long to confirm etc). Also, if anybody tries to send any of the coins produced after the "surrounding", the banking will not be able to receive it.. it will probably treat them as "illegal coins" what may raise alerts too.
It seems very difficult.

but it should absolutely not be relied upon as security measure

You would need to know the IP address(es) being used for bitcoin by the bank. It might not be easy to discover that.

Good idea. Bitcoin's network is weak, and you can do a lot of mischief if you can totally surround someone.

The attack as you described it would be entirely possible if not for block timestamps. Difficulty is based on block timestamps, and blocks are rejected if their timestamps are too far from reality. An attacker attempting your attack would therefore have to match the difficulty progression of the real network in order to get a final timestamp that matches reality. If an attacker can do that, then they can overcome the real network.

An attacker that is totally surrounding the bank can put it on a separate chain. The attacker will produce blocks slower than the real network, but the bank will accept them if those are the only blocks they see. This allows double-spending attacks against the bank, which may result in the bank accidentally becoming fractional-reserve. A later version of Bitcoin will probably produce a warning when it's receiving blocks more slowly that it should.

In the future Bitcoin might support an ultra-lightweight mode that doesn't even download full blocks. This mode is clearly not meant for banks, but if the bank is running in this mode and surrounded, you can generate fake coins and make the bank take them. The bank can't verify the transactions for itself, so it relies on hash trees in the block chain. If the chain is bad, then even a transaction for 21 million BTC could be considered valid by such a client.

See http://www.bitcoin.org/wiki/doku.php?id=weaknesses#cancer_nodes

Actually surrounding someone is difficult because Bitcoin will only make outbound connections to IPs on different /16 networks. Still, a bank would be wise to set -maxconnections=50 and connect to a couple of fallback nodes.

You can't make ANY "fake" coins accepted without first taking over more than 50% of the network processing power.

Well - Actually you cannnot make "fake" coins at all.
Even if you take over 51% of network, if any coin does not match the blockchain, it will be rejected by the rest (49%) of the network. The only thing you could do is double spend some transactions.

I'm not going to try to correct this, it's too much work for one person.  Basicly, bank fraud may be possible, but not the way that you propose.  I don't think that you understand how it all works yet.

Disclaimer: I have some experience in developing p2p network (freenet), but is a newbie in bitcoin. Please correct me if I am wrong.

Observations

• Generating private-club fake coins are easy
  Get 100 notes from the "cloud", or a botnet. All "easy" coins are yours.
• Getting fake coins accepted network-wide is hard
  When the network grow large, it is impossible.
• But you don't need it accepted network-wide
  Banks, such as MyBitCoin, does not return the same coin you save. If you can make it accept your fake coin, you can get some real coin from it.
  

So the idea is: Fraud the bank.

Some idea how to connect to the bank:

• Dominate the bank's peer connection:
  
  • The -addnode= / -connect= option, does it work that way?
  • DoS the bank (or bank's peers), force the bank bootstrap/connect new client
  • Exploit the topology. I don't know if bitcoin work this way, but some network (like Kad and Freenet) have certain topology. Exploit it to get as near to the bank as possible.
• Wait until the bank crash.
    If the bank don't backup all its blocks, it have to re-download from the net, make this more then possible.

I have no idea if this really works. All these idea seems to be easy to protect from, provide that you know the attack. This post is just trying to raise some awareness, or just some idea brainstorming.