Bitcoin Forum
December 03, 2016, 09:48:45 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Intercept/reject proof-of-work broadcast?  (Read 1096 times)
w128
Newbie
*
Offline Offline

Activity: 14



View Profile
May 24, 2011, 07:45:36 PM
 #1

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?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Garrett Burgwardt
Sr. Member
****
Offline Offline

Activity: 350



View Profile
May 24, 2011, 08:02:30 PM
 #2

What have I missed?


a large number of pooled, colluding clients

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.
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
May 24, 2011, 08:27:21 PM
 #3

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

How often do you get the chance to work on a potentially world-changing project?
w128
Newbie
*
Offline Offline

Activity: 14



View Profile
May 24, 2011, 08:51:39 PM
 #4

What have I missed?


a large number of pooled, colluding clients

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.

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.

Quote from: Garrett Burgwardt
Search the forums for "Sybil attack" and you'll find relevant discussion.

Thanks. I'll have to check it out.
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
May 25, 2011, 02:55:12 AM
 #5

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.

You are confusing mining clients with network nodes.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
w128
Newbie
*
Offline Offline

Activity: 14



View Profile
May 25, 2011, 03:14:21 AM
 #6

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.

You are confusing mining clients with network nodes.

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?
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!