Topic: Intercept/reject proof-of-work broadcast? (Read 1359 times)

That's true.

I did refer to the machines producing 1/3 of the total hashrate as "1/3 of the network".

Is there any way to estimate the actual network size?

You are confusing mining clients with network nodes.

Would it really be that hard?

With some truly enormous (1/3 of the network and growing) pools running and the incentive of very real money to be mad is it that far-fetched to think that pools could become aggressive/defensive?

The operator or some member could distribute a "installer" which would perform these actions automatically. I expect most people wouldn't care if it benefits their bottom line and others could rationalize it under the guise of a defensive measure.

Also, these interference nodes wouldn't have to be big time hashers. A botnet could be put to use for the simple purpose of diluting the number of useful broadcast recipients or triangulating on DDoS targets rather than hashing directly as is more often suggested.


Thanks. I'll have to check it out.

Search the forums for "Sybil attack" and you'll find relevant discussion.

Very tough to pull off, to begin with. And by default IIRC you try to spread out your connections based on IP or somesuch, besides the fact that you connect to a random number of things, and can always connect to a fallback node.

I feel like this must have been asked before but, I haven't been able to find anything through searches.

I found lots of discussion on double-spending and other attempts to steal or falsify transactions but not much more more indirect methods of interfering with or gaming the network.

What if anything is there to stop a large number of pooled, colluding clients from rejecting or delaying acknowledgement of connections and/or transactions and proof-of-work from other clients?

The idea would be to reduce the collective hashrate of non-friendly clients relative to the friendly pool in order to allow more time for the production of pooled blocks prior to a difficulty increase.

The method would be a packet filter or proxy on each colluding client that would falsify socket timeouts or delay acknowledgements to non-friendly clients. It would only do this some percentage of the time in order to avoid raising suspicion or blacklisting (if that's possible) by the nodes it is interfering with.

An extension of this idea could be to create a sort of distributed sniffer from colluding clients which would identify specific addresses producing a large amount of work and force them offline.

What about flooding non-friendly clients with garbage transaction data?

What have I missed?