You didn't installed Sierrachart to default directory, did you? Please add "-d" option and specify the full path to "data" directory of your sierrachart installation, for example

GAE has no problem with json, so no problem with encoding here. However GAE does not support TCP sockets and persistent connections, except "Channel API", which is highly proprietary stuff and there's no reason to include this into Stratum "standard". However HTTP transport is definitely the way how to implement Stratum on GAE. Are you using Python or Java on GAE?

I'm going to implement set of unit tests, so it should be pretty easy to test if alternative server implementation fits all protocol requirements. I'm still working on another project right now, but I'll be back on Stratum in few days.

Nice, I'm going to test this service soon. I see this useful for miners. If they want to save x% of their mining profits and sell immediately 100-x% on the market, this is pretty nice way how to automate it without any additional scripting...

What keeps you from using numerical pin when the password field accepts alphanum characters?

I'm using gesture for unlocking the phone, but it's incredibly easy to see the gesture if you're near me. Of course using 10-character pin for unlocking the phone every ten minutes will be more secure, but also very annoying.

Using pin for BitcoinSpinner is definitely better way to secure my coins, because PIN isn't used so often and it's easier to check that nobody is watching my fingers.

EDIT: It does not need to be numeric pin, but simply any password securing the client's GUI.

Btw I vote for PIN protection of the GUI, too. As I understand, the private key is stored in some secure place already, but I will feel much more comfortable when it won't be so easy to steal my coins when I'll leave my phone alone for a moment.

Let's wait to DGM, ok?

Nothing.


Alongside of other reasons, pool provide you only block HEADERS, so you don't have complete block to broadcast it to network. This has been discussed wildly here, use "Search" feature of this forum.

I have Osiris on Windows, running for weeks without any issue...

No, they have just higher variance, but it averages out itself (after 1000-10000 shares).

As I said, everything has been discussed before. Adding "loyalty shares" won't work as expected because of low hashrate miners. Are they mining, idling or hopping? Upgrading the rewarding system is definitely the way to go.


Please... read all the stuff and don't open the discussion again... Seriously... Edit: I recommend you papers of Meni Rosenfeld, he has very nice calculations for almost every method.

Sargasm, things is more complicated that it seems to be. I never said that there aren't pool hoppers. There are a lot of calculations for various pool models for pool hopping and it's known that score method used on my pool have some minor flaw from the view of pool hopping. Actually only PPS (requires higher fee) and double geometric (very complicated) methods are supposed to be fully hop resistant, but I don't want to open ANY discussion about this now, because everything has been discussed before.

FYI I'm working on rewriting the pool to double geometric method, to satisfy all people who're complaining about even very minor chance of extra gains for pool hoppers. Unfortunately double geometric is _really_ complex method and it does not scale well for large pools. Btw I discussed scalable algorithm of DGM with Meni Rosenfeld on Prague conference...

Back to topic. Although the variance for short rounds is done by pool hoppers, it does not mean it's your loss. It's because you forgot that thanks to pool hoppers, there's higher hashspeed in shorter rounds. Actually the hashrate for long rounds (so hashrate average cleaned from pool hoppers) is around 1350-1400 Ghash, on the beginning of the round there's hashrate slightly over 1500 Ghash, which fits your number pretty well. Don't forget that it's even more complicated, because pool hoppers don't disconnect at same time, but they use various methods and are following various pools. The pool hopping benefit is *teoretically* around 5% of pool hopper profit, BUT hoppers are working on the pool just for very short period of time (depends on selected algorithm, but less than 5 minutes?), which means that their average block reward in absolute numbers is very small comparing with full-time mining. So only 5% of this tiny profit is the real loss for others.

I'm not talking that it isn't a problem. But the real loss done by pool hoppers is insignificant in the global view (it's much lower than natural variance in bitcoin mining itself) and it's better to wait to correct implementation of DGM than hurry and break the reward calculations in some strange way.

Jan, thank you for fixing the subBTC bug, it works for me now.

Newest poclbm miner (git version only, will be released as new version in following days) has nice support for Tor mining. Thank you m0mchil!

1. Install Tor on mining computer. No special configuration is needed, client mode (default) is enough.
2. Example command to run poclbm over Tor:


That's all! poclbm over Tor supports long polling and ntime rolling and our testing computers achieved ~1% stale ratio, which is pretty good result for mining over high latency network like Tor.

Tor mining have some benefits. Not only that mining is purely anonymous then, but it's also DDoS resilient, because Tor service on the pool is running over secret IP...

As you can see on stats page, there are already some miners connected over the Tor. Happy mining!

I was thinking about it, but AFAIK Sierrachart's scid file don't provide data structures for storing bids and asks separated. There's only bid/ask volume which isn't enough...

Solution: Don't pick dly. Use only Intraday charts and select .scid files.

About other errors  - you can freely ignore all errors about unknown symbols and data feeds. It's because sierrachartfeed does not use "official" feeds from forex/commodity markets.

Can you please run sierrachartfeed from terminal window? It will print some error message which can help me track the problem...

I was thinking about it too, but I discarded it thanks to my experience with "user agent" in current getwork API. It's almost impossible to filter any useful information because some miners are filling it with garbage. For example, people patching their miners don't change miner identification, so I often see that miner advertising itself as "poclbm/somenumber" behaves differently than real poclbm in this version.

But I think I found cleaner solution using prevhash. prevhash from local bitcoind is giving exactly the information which pool needs to check if client is using correct blockchain, even if he's using some weird home-baked miner with manually entered miner/bitcoind version. It's pretty long story, but I hope it will be clear from the proposed protocol (FYI built on the Stratum infrastructure).

Well, this is what I wanted to know. So shares won't be calculated for miners with "wrong" bitcoind version.


There is only the possibility that >50% of bitcoind's network will support p2sh, but <=50% of P2Pool users won't support p2sh. Then even user who updated his bitcoind will mine to the black hole, because his shares will be rejected by p2pool, although they would be valid on bitcoin network itself.

I'm not saying it's bad, I'm just sumarizing how I understand it.


I'm working on the mining protocol for the pools, where miners (workers) will have the power to choose transactions what they want to include into the block. I started to think about this seriously after I saw the criticism in op_eval and p2sh discussion that pool operators are holding too much power.

Actually I'm on the track of protocol which will allow full democracy of the bitcoin miners like in p2pool, but still with possible zero variance (even pps with difficulty 1 payout scheme), which is something what is missing on p2pool. It should be also DDoS resilient as there won't be any real benefit in attacking the server which will just collect shares and stats...

Thanks to this, I'm solving some potential issues with outdated miners. Of course witholding attacks (and other attacks) are still possible on the pools, but I just want to be sure that honest miners just using outdated software cannot break the pool itself. I think that I already found the solution, but I need to think about it a little more. But I hope that I'll publish my proposal soon...

Oh, really? I didn't know that! :-P By partially solved block I meant a share or generally a proof of work, of course. I wanted to avoid "share" because it is used for diff1 work used in standard pools, but it doesn't matter now.


Thank you for the answer, this is exactly what I asked and also what I was affraid of. Actually there's big difference between block withholding and producing invalid blocks. For performing block witholding your malicious activity is needed to BREAK the pool. But when the bitcoin rules will change (like p2sh in the blockchain), your activity is needed to NOT BREAK the pool.

Maybe I'm missing something, but rolling P2Pool to p2sh will be really painfull unless I'm missing something. I'm asking because I'm working on getwork API replacement and I hit similar issue like I'm discussing here, so I'm asking how other people solved the issue.

[qupte]
Blocks wouldn't be rejected.  If the bitcoind is out of date it will see p2sh transactions as invalid and not include them.  The block produced would still be valid much like mining a completely empty (except coinbase) block is valid now.
[/quote]

Well, this isn't so easy. When there will be first p2sh transaction included in main blockchain, outdated client will make a branch because first block with p2sh won't be valid in outdated bitcoind...