Bitcoin Forum
February 07, 2025, 09:26:58 PM *
News: Community Awards voting is open
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Bitcoin Discussion / Dwolla on: May 27, 2011, 12:37:20 AM
Dwolla is tiny, having taken on just $1.3M in funding since starting up. I'd imagine bitcoin is rapidly growing part of their business.

How neat would it be for some bitcoin baron to buy a stake in the company with money generated from bitcoin and cashed out through Dwolla?
2  Bitcoin / Bitcoin Discussion / Has bitcoin spurred your interest in technology/economics? on: May 26, 2011, 08:22:03 PM
For me, the interest in technology was already as it's what I do for a living. Bitcoin has certainly lead me to learn more about economics and convinced me to try my hand at investing beyond standard retirement contributions.

How about you?
3  Bitcoin / Mining / 1 block / 10 minutes yet blockexplorer shows 278 blocks in the last 22 hours? on: May 24, 2011, 10:13:40 PM
Can someone explain and make me feel dumb?

126158 @ 00:00:48 to 126436 @ 22:05:45

4  Bitcoin / Bitcoin Discussion / Intercept/reject proof-of-work broadcast? on: May 24, 2011, 07:45:36 PM
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?
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!