Bitcoin Forum
April 20, 2024, 06:10:59 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Intercept/reject proof-of-work broadcast?  (Read 1332 times)
w128 (OP)
Newbie
*
Offline Offline

Activity: 14
Merit: 0



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?
1713593459
Hero Member
*
Offline Offline

Posts: 1713593459

View Profile Personal Message (Offline)

Ignore
1713593459
Reply with quote  #2

1713593459
Report to moderator
1713593459
Hero Member
*
Offline Offline

Posts: 1713593459

View Profile Personal Message (Offline)

Ignore
1713593459
Reply with quote  #2

1713593459
Report to moderator
Even if you use Bitcoin through Tor, the way transactions are handled by the network makes anonymity difficult to achieve. Do not expect your transactions to be anonymous unless you really know what you're doing.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1713593459
Hero Member
*
Offline Offline

Posts: 1713593459

View Profile Personal Message (Offline)

Ignore
1713593459
Reply with quote  #2

1713593459
Report to moderator
Garrett Burgwardt
Sr. Member
****
Offline Offline

Activity: 406
Merit: 256


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
Merit: 2216


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 (OP)
Newbie
*
Offline Offline

Activity: 14
Merit: 0



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
Merit: 1024



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.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
w128 (OP)
Newbie
*
Offline Offline

Activity: 14
Merit: 0



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:  

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