Edit: better still how about tunnelling the workers in and shutting EVERYTHING else out?
Then people would have to foward ports and use a special client. Why special client? Are there problems with RPC across TCP/SSH? And how much more work is it than stopping miners etc all the time? We need to secure these pools, it is as obvious as the nose on your face. I think creighto says the enemy of the good is the perfect. Anything better than nothing. The SSH CPU overhead of thousands of miners connected at once may be a lot. Ready to donate more? BTW, SSH attempts can still be started and left to time out without sign-on. So, essentially the same attack vector [unintentional or intentional] still exists. Yeah had thought that might be the case but was hoping not ... so what to do? Register IP's with pool, can't imagine that would be popular or that simple either. My hunch is they DDOS in the hope of colliding with enough work packets that eventually they'll start hitting golden tickets .... if the pool and miners were connected across Tor they wouldn't even know which packets to aim at ... but back to the other overheads there like ssh. Tough one. |
|
|
|
|
Good article. Well thought out and researched.
|
|
|
|
it does no good to sell off all your coins when the market is only so deep and at the end you'd be giving away coins for free eventually. Right now if that guy with 370,000 coins sold he would only be able to sell 9500 of them for about 185,000 bucks (not including dark pool orders that may exist)
the best thing for everyone including early adopters is to slowly sell their coins, maybe a few hundred at a time, so that more people can get involved while at the same time allowing for maximum "value" to be obtained.
Then again as has been mentioned before a lot of early adopters are involved with this project to see it come to fruition as a currency. There is not a whole lot in it for them to "crash" the system. Then again if they did sell off everything and prices plummeted back to near nothing I am sure there are plenty of people with offers on mtgox for like 10,000 coins at 10 cents per just waiting to get back into it/reinvest
The point is they have the power to completely crash the system. Whether or not that will ever be used can only be told by time, but removing the possibility of it ever happening would go a long way into making bitcoins an accepted and more stable form of currency, imo. Perhaps in only several years bitcoins could be worth $1000 or more. Imagine losing thousands of dollars of value just because someone decided to put 100k on the market. After getting burned once, the possibility of being burned again will be very high in peoples' minds, and the bc value will never again reach the same high. Again I don't know the specifics about the hash difficulties and if it was programmed to do this from the outset, but getting one hundred thousand percent returns in a matter of years is not in any way sustainable or good for the future of bitcoins. So I take it from these sentiments here that you would like to buy in ... or you'll never buy in, it is not clear. On the one hand you are saying they are worth an enormous amount of money (too much power for people who's motives you are impugning), yet at the same time they risk crashing to zero. Seems like a paradoxical position. |
|
|
|
|
I think all you've managed to do their is secure a link between two machines on your home network and poke out an IP link to the pool across the Internet. I don't think you've secured the link to the pool at all. For that I'm pretty sure you need to connect with a sshd on the other side.
|
|
|
|
I've found a page that has a simple Python PID controller. http://code.activestate.com/recipes/577231-discrete-pid-controller/#The recipe gives simple implementation of a Discrete Proportional-Integral-Derivative (PID) controller. PID controller gives output value for error between desired reference input and measurement feedback to minimize error value.
#More information: http://en.wikipedia.org/wiki/PID_controller
#
#cnr437@gmail.com
#
####### Example #########
#
#p=PID(3.0,0.4,1.2)
#p.setPoint(5.0)
#while True:
# pid = p.update(measurement_value)
#
#
class PID:
"""
Discrete PID control
"""
def __init__(self, P=2.0, I=0.0, D=1.0, Derivator=0, Integrator=0, Integrator_max=500, Integrator_min=-500):
self.Kp=P
self.Ki=I
self.Kd=D
self.Derivator=Derivator
self.Integrator=Integrator
self.Integrator_max=Integrator_max
self.Integrator_min=Integrator_min
self.set_point=0.0
self.error=0.0
def update(self,current_value):
"""
Calculate PID output value for given reference input and feedback
"""
self.error = self.set_point - current_value
self.P_value = self.Kp * self.error
self.D_value = self.Kd * ( self.error - self.Derivator)
self.Derivator = self.error
self.Integrator = self.Integrator + self.error
if self.Integrator > self.Integrator_max:
self.Integrator = self.Integrator_max
elif self.Integrator < self.Integrator_min:
self.Integrator = self.Integrator_min
self.I_value = self.Integrator * self.Ki
PID = self.P_value + self.I_value + self.D_value
return PID
def setPoint(self,set_point):
"""
Initilize the setpoint of PID
"""
self.set_point = set_point
self.Integrator=0
self.Derivator=0
def setIntegrator(self, Integrator):
self.Integrator = Integrator
def setDerivator(self, Derivator):
self.Derivator = Derivator
def setKp(self,P):
self.Kp=P
def setKi(self,I):
self.Ki=I
def setKd(self,D):
self.Kd=D
def getPoint(self):
return self.set_point
def getError(self):
return self.error
def getIntegrator(self):
return self.Integrator
def getDerivator(self):
return self.Derivator
If any of you Python wizards feels like patching this into your temp. fan control algo it would probably be adequate to eliminate the 'hunting' phenomena, as the fan chases the temperature around. The current temperature is "measurement_value" I think. P,I, and D are the tuning parameters for the controller. Set-point is what temp. you want the card to be. The output will be some multiplier for the fan speed (normalised would be 0-1, i.e. multiplied by 100 to get fan speed in percentages). Anyone who feels like twiddling, can tune the PID parameters, they'll probably have long time constants because of the nature of the thermal inertia of the heat sinks, etc. It needs to perform this loop at least 10 faster than the shortest time constant, which is probably pretty long given the thermal nature, so keep the 30 or 60 second loop is probably adequate. |
|
|
|
Eleuthria,
I would be willing to donate a little more if we could indeed tunnel through SSH on the standard SSH port. That port is not blocked at my office firewall, and securing the traffic would be awesome. Right now, ports 8332 is blocked at work, and I was going to have to figure out a way of setting squid proxy on my co-located web server to get traffic to BTCGuild.
Just create your own SSH tunnel to a machine on your home network. Then setup a port forwarded [tunneled through SSH] to btcguild.com:8332 and make it localhost:8332. Point your miners at 127.0.0.1 instead of btcguild.com and you are ready to go. You don't need a service for this. Is that feasible? That wouldn't be end-to-end though right, it needs to connect to a server on the other side for that? Always have trouble wrapping my head around which way the tunnel is going on those remote port forwards  Can you post the command sequence? Ta. |
|
|
|
|
Seems quite well done.
How long has this company been in business? Based in Australia, correct?
Any media reports or other third party references?
PS: Might want to implement https for login page to a brokerage account.
|
|
|
|
|
Inflammatory, illogical, with a sensationalistic headline. No place in this forum.
Moderators? Trash this one?
|
|
|
|
Resources ARE limited period Define resources. REAL scientists define the terms of their arguments. |
|
|
|
|
Hey!, if we keep ratcheting the decimal to the right maybe we can convince people (dumb-ass economists) that it is inflating (not deflationary)?
See, it still costs $1 for 1 BTC .... (while moving the decimal place quietly to the right one more notch).
|
|
|
|
not as much as I would like... next time when I buy 200-300 of these babes, I'll push for some more serious discount, though.
Or get supplier list price access and on sell them in BTC  (In a gold rush, it is the people supplying the equipment that end up with the gold. Dealing with customers is PIA though.) |
|
|
|
|
Vladimir ... do they do bulk discounts?
|
|
|
|
Go ahead and write it.  Okay, I'll give it a go. Never done anything with creating man pages before except read them. And can't say I'm the world's expert on bitcoin functionality by a long shot but if I put something out there others can improve on it. Any, all constructive input welcome. (I decide what's constructive until someone else takes it over). |
|
|
|
Edit: better still how about tunnelling the workers in and shutting EVERYTHING else out?
Then people would have to foward ports and use a special client. Why special client? Are there problems with RPC across TCP/SSH? And how much more work is it than stopping miners etc all the time? We need to secure these pools, it is as obvious as the nose on your face. I think creighto says the enemy of the good is the perfect. Anything better than nothing. |
|
|
|
Parsing through about 2 million lines worth of logs right now after running a sample on the first 5 minutes. Will likely be banning some IPs based off what I saw in the 5 minutes (people with over 1000 requests for work but less than 10 results sent back, some with 0).
How about deny everything and have people enter their worker IPs when they setup workers. Then just open up the source IP for each worker. Do this. Edit: better still how about tunnelling the workers in and shutting EVERYTHING else out? Here, Simplest implementation to secure mining traffic and make shutting out DDOS easier; miners run something like this in a terminal $ ssh -L 8332:btcguild.com:8332 username@shellserver need username and passwords for ssh (do nothing else but login and connect to bitcoind_server on port 8332) and they can run their miners using this ./poclbm.py -d1 --host=localhost --port=8332 --user=worker_name --pass=worker_password (make sure no local bitcoind using 8332, e.g. solo mining, so could also change that but kept it simple to begin with). |
|
|
|
Okay. So my reasoning goes;
- there needs to be some incentive for individual miner to submit lesser difficulty shares to alternate blockchain
- given the incentive, the individual miner will submit as many lesser difficulty shares as possible to the alternate blockchain
- given the incentive most, if not all, miners on BTC network, will submit as many lower difficulty shares as possible to alternate blockchain
- net effect, the hashpower being pointed at alternate block chain will be nearly same as that pointed at BTC, hence difficulty will rise on alternate block chain until they are synchronised
This reasoning is correct, but you're assuming that the block rate in the alternate network is the same as in btc (10 min per block). That's not necessarily true. Good point, thanks for that. So, choosing the block rate of an alternate chain utilising the same hashing network, is tantamount to choosing it's difficulty ratio with the main BTC chain. And I propose that this maybe "fix" its relative security, desirability and thus price relative to BTC. E.g. The alternate block chain could have a block rate of 1 per minute (faster confirms) but it's network difficulty would be 1/6th that of BTC and thus it would trade at approx. 1:6 ratio with BTC. |
|
|
|
If you are reading this thread, and you didn't understand any of what I said above, please consider a different approach to mining, or get a demo board, or wait until someone has a tested and working design that they are willing to produce and sell. You think will stop them trying?  Ovens, solder, chips ... what could possible go wrong? It's like a chemistry set for grown-ups this place. |
|
|
|
|
Show Posts
