How to protect B from this relatively largest miner attack?

[Forp]

Hi there,

in the fallout of the recent theft of 0.5 M there was an interesting discussion on a german board and a suggestion for an attack. I am not sure if we can withstand this attack and thus post it for comments here.

Mallory has a good mining rig / pool. He has by no means the majority of the hashing performance but he knows he has the largest or second largest hasing performance.

He now sends to every participant a different tx and starts building a block on yet another tx. Everyone will solve HIS version of the tx and Mallory will win, assuming nobody has more hashes / sec than him.

Note: We do not assume absolute majority of hashes, but (only) being the largest participant.

According to my understanding the attack would work, although it might not be practical.

Opinions?

[MoonShadow]

You need to rewrite this, it doesn't even make any sense.

[Forp]

You need to rewrite this, it doesn't even make any sense.

Sorry. I just corrected two typos which might have been misleading. What else is not clear? Or am I too short?

The idea is that Mallory is doublespending on a massive scale - sending a different transaction to EVERY participant in the net. He will win the longest block, assuming he has the largest mining rig.

[Raistlan]

Forp, I think you may have some misunderstandings of how things work. You may be confused on what a transaction is versus what a block is, or some other misunderstanding that makes your scenario really hard to understand, even to the point of making it hard to understand where the misunderstanding lies.

Maybe if you can break it down into smaller parts, it would be easier to tell where the disconnect is between what you are trying to ask and what us readers see.

[MoonShadow]

You need to rewrite this, it doesn't even make any sense.

Sorry. I just corrected two typos which might have been misleading. What else is not clear? Or am I too short?

The idea is that Mallory is doublespending on a massive scale - sending a different transaction to EVERY participant in the net. He will win the longest block, assuming he has the largest mining rig.

Ah, I understand now.

I see two problems with your scenario...

1) First, you have no idea how the bitcoin blockchain proof of work system works, and..

2) you have no idea how pool mining works, either.

[[Coins!]]

Ah, I understand now.

I see two problems with your scenario...

1) First, you have no idea how the bitcoin blockchain proof of work system works, and..

2) you have no idea how pool mining works, either.

zing~

[Maged]

You need to rewrite this, it doesn't even make any sense.

Sorry. I just corrected two typos which might have been misleading. What else is not clear? Or am I too short?

The idea is that Mallory is doublespending on a massive scale - sending a different transaction to EVERY participant in the net. He will win the longest block, assuming he has the largest mining rig.

Uhh... I think you're trying to describe the "Finney Attack". It's why nobody should accept high-value transactions that aren't yet confirmed.

[MBH]

A 1GHz single core CPU has the same "chance" of solving a block as a beowolf cluster of graphics cards. It's not just the sheer amount of raw generation of blocks, but there's also a "chance" or "luck" factor where your machine gets to solve something before another.

[Forp]

Maybe if you can break it down into smaller parts, it would be easier to tell where the disconnect is between what you are trying to ask and what us readers see.

@Raistlan:
========

I am sorry, Raistlan, if I was too cryptic.

The idea, as I understood it in that German forum, is as follows:

Assume, Bob001, Bob002, ..., Bob999 all have 1 GHash/sec and Mallory has 10 GHash/sec. Mallory has a faster miner than all other guys on the network but he does not hold the absolute majority (ie. 50% or more) of the networks mining capability.

Assume, bad guy Mallory knows the addresses of the good guys Bob001, Bob002, ..., Bob999.

Moreover, Mallory has 10 BTC. Mallory now designs a transaction of spending these 10 BTC to Bob001 and sends it to Bob001. He designs another transaction of spending these 10 BTC to Bob002 and sends it to Bob002 - and so on. He also sends a transaction of spending these 10 BTC to another Bitcoin address he holds himself.

Eventually Bob001 starts working on sealing this transaction in a block and so do Bob002, ..., Bob999. And so does Mallory, working on sealing the transaction sending the money to his other address.

Mallory will be first in finding a valid block. Not always, but most of the time, since he has the fastest miner.

 

AHA. And I now realize that this probably was the mistake I made in evaluating this attack. Mallory may have a larger chance to find a sealing block than an individual Bob001 by factor 10, but he will not have a larger chance to find a sealing block than ANY Bob*. Of course he is competing against all other miners combined. Thus, chances are much higher that there is just ANY Bob* to get his block done first and so Mallory's plan will not work.

I hope this is fine by now ?!  


@Maged:
=======

Thank you very much for pointing out the Finney Attack: I was not actually suggesting to accept a transaction without waiting for confirmation. I assumed that Mallory would manage to produce a longer block chain with his version of the transaction faster than all the others - but this is plainly not true, there was a reasoning mistake by my part here.  

[Forp]

A 1GHz single core CPU has the same "chance" of solving a block as a beowolf cluster of graphics cards.

Agree and disagree.

We cannot talk about a chance of solving a block without giving a time period during which the machines try to solve the block. 

No machine finds a block within 1 [nanosecond] and every machine finds a block within 1000 [centuries].

But, if we define "chance" as "probability that a machine finds a block within 1 second", of course a beowolf cluster of graphics cards has a larger chance than a 1GHz single core CPU. The "chance" (if defined that way) is linearly proportional to the hashing performance.

That was the part where I disagree with your posting.

The part where I agree with your posting: Solving a block is not a deterministic type of task but a random one. So if many nodes try to solve it and if their random number generators are indepent (and seeded differently), then their "solving power" in terms of "chance" actually adds up. And this is exactly where my thoughts went into the wrong direction. 

Thanx very much for your posting - it made me think and help me understand the problem of my attack.

I hope I got it right now 

[Forp]

@MoonShadow, @Coins!
====================

Unfortunately I know of no specification of the protocol which I understand completely - with the exception of some 10.000 lines of code C++, which I am currently in the process of reading and adding the missing commentaries, but this still takes a bit of time.

The orginal paper of Satoshi leaves many black spots and the Wiki specification describes messages formats but not the overall logic. I still did not succeed in filling in all the black spots.

All in all, your assessment of my situation certainly is correct, which is exactly the reason why I am here in this forum. I want to learn, I want to discuss, I want to improve my understanding of Bitcoin and I want to contribute with what I am able to. I am asking myself what went wrong in our parts of the conversation in this thread, since "zing~" isn't exactly helpful. 

And, yes, I am still having troubles understanding when and how a node decides which transactions are to be packed into the same / next block. Is this done by every individual mining node? If it is, which I assume, I see another issue: Currently less and less nodes are mining on their own and more and more are joining a mining pool, which hands out shares to their workers. Does this mean, the mining pool "supernode" decides on this question? If it does, then aren't we losing the advantage of a decentralized system, since we are having less and less "supernodes" deciding on what all workers are workign on?

I am sorry, if I am wrong with my assumptions. I am trying to understand.

 

[MoonShadow]

And, yes, I am still having troubles understanding when and how a node decides which transactions are to be packed into the same / next block. Is this done by every individual mining node?

Within parameters, yes.

If it is, which I assume, I see another issue: Currently less and less nodes are mining on their own and more and more are joining a mining pool, which hands out shares to their workers. Does this mean, the mining pool "supernode" decides on this question?

With regard to the pool, the pool server decides the transactions to be included in the block.

 If it does, then aren't we losing the advantage of a decentralized system, since we are having less and less "supernodes" deciding on what all workers are workign on?

Yes and no.  There is some centralization going on with pools, but there are balancing forces at play even with pools.

I am sorry, if I am wrong with my assumptions. I am trying to understand.

Your original post seemed to imply that you believed that pool servers distribute transactions to be processed, which is not the case.  Pool miners are only hashing an 80 byte long header and only incrementing the nonce.  It's the server that builds the block and merkle tree that begets the merkle root as part of the header.

Solo mining works in exactly the same way, except the pool miner and the server are on the same machine.

[Forp]

Much clearer now. Thanx a lot !