Topic: [ANN] Stratum mining protocol - ASIC ready - page 31. (Read 146166 times)

I had tried manually installing twisted and python no luck. That was the only thing that would get my machine to allow the install without errors.

Stratum 0.8 is the new one?

Good to know it's working for you. python-devel is suggested on github howto, but I don't see a reason for python-crypto, pyOpenSSL and especially for zope. Are you sure it won't work without these dependencies?

I fixed it! For any others having this problem on ClearOS or CentOS 6.x

Run this "sudo yum install python-devel python-crypto pyOpenSSL zope"

Latest twisted can be found here: http://pypi.python.org/pypi/Twisted/12.2.0 and it is platform independent, so I don't see any reason why it should not work for Centos6 as well. It's quite strange that setup.py don't install latest version automatically.

el6 -> CentOs6

Looks like your platform don't have newer version of tsited? What the hell is el6?

Btw it should work with older version of twisted as well, after I fixed the bug itself. Give it a try.

It returns an error when trying to install twisted during setup. I will try to get a capture of the error.

Yes, it's quite old version. I just pushed new version of the proxy to the github, please update.
New version requires newer twisted and I removed that problematic code (I used one internal variable which may be removed in the future releases). This should fix your issue.

You should run "python setup.py install" as a root to install newest twisted.

This help?
Package python-twisted-8.2.0-3.1.el6.noarch already installed and latest version
Nothing to do

Can I ask you which version of Twisted do you have installed? I'm using some feature which looks missing on your machine...

I am getting this message along with a bunch of rejects after the message. I am sure it is probably due to my lack of Linux knowledge.

Joshwaa - yes. What's the problem?

Slush would this be the correct place to ask about a problem with my STRATUM install on a linux box?

In previous days you stated:
a) GBT is decentralized
b) GBT can do the same thing as getwork
c) GBT can do the same thing as stratum

Can you then elaborate, how you can do the same as stratum and getwork decentralized *at the same time* with single implementation of GBT? You obviously cannot. Because you're talking about different use cases of the specs every time.


Actually you're saying that operators are evil (although all blocks generated by pools can be easily checked in block explorer) and miners honest, right?

Of course every sane pool op *have to* check submitted shares. Checking PoW is the main purpose of the pool and he will fail if he will accept broken share in any way.


Stop this bullshit, please.


This is about free market. Only those who can minimize running cost will survive. And we're talking about multiplying montly costs for running pool, when deciding between GBT (full implementation, not using "shortcuts" as not validating all shares) and Stratum. Of course that pools which can minimize running cost can go lower with the fees.

last time i used it my payouts where not close to expected (but this is about half year ago). and i had a problem because i got so many small payouts that i have to pay a huge fee whenever i wanted to send out the bitcoins (ok, i could use mtgox wallet to avoid that)

i would consider p2pool a success if they have about 40% of the network - but i dont know if they even have a solution to handle that situation.

Care to elaborate at what p2pool has failed? I'm pretty satisfied with it myself and I monitor actual payouts vs expected payouts quite closely...

No, GBT is always decentralized; while a centralized extension would be possible, there isn't one (yet?).
There are other easier ways to cheat the pool out of blocks than including phony transactions, so if your pool is really so strained you could simply skip validating them. The only risk is a miner who is accidentally making invalid blocks - that can likely be countered by doing a full check only occasionally. Bandwidth use is mostly unchanged, if you use workids (or similar) to cache the templates being mined.

Hindsight is always better, but... it would have been nice if you had worked with us and brought up your concerns sometime between February and July so GBT could have taken them into consideratoin. It's a shame to need two totally unrelated protocols for almost identical use cases. I also don't see why miner software authors (whose development is mostly made up of donations) should be expected to have to deal with it simply because a few big pools (with fees and income) demand yet even more savings on top of what GBT already gets them. It makes sense for some individual miners (who run their rigs off cellular modems or something?) might need to reduce bandwidth, but there's no reason they couldn't run a private proxy that does a Stratum-like centralization on their own non-limited connection somewhere.

Option implies miners have a choice to mine decentralized on your pool. Are you saying that will be possible?

"Almost" decentralized network only protects against 51% attacks (and then, only if the few people making up 51% aren't compromised); there are other attacks that can be done with less.

I'm sure you're aware since you noted sarcasm, but just to clarify explicitly: there is no risk at all to the Bitcoin network from "centralized" manufacturing provided the distribution/use is indiscriminate (which BFL has promised, although other ASIC vendor(s) aren't so Bitcoin-friendly apparently).

LoL, your point

Looks like you care about decentralized mining, but don't care about centralized manufacturing of miners, which is much bigger risk for bitcoin network

you're right... as soon as i get my bfl asic i'll take eligius
as i like functional programming its a natural choice anyway.