|
I made all the nodes support tor:
stratum+tcp://zy2e3jz56abvdndx.onion:3333/ pdx
stratum+tcp://4s4vswb6lcmpm4wy.onion:3333/ iad
stratum+tcp://aqkdl2ssyrxymggx.onion:3333/ dub
I'll be interested to see if anyone uses that.
|
|
|
|
And don't forget: Satoshi Dice has probably paid more in transaction fees than the entire network combined throughout history (not counting mistakes and/or testing transactions).
Dice payouts include fees, as do most of the bets that go there in the first place.
2721 BTC to date (not including what players may or may not pay to get transactions to us). |
|
|
|
fireduck,
homepage does not show users/addresses anymore... ?
spiccioli
I know, I was having some database load issues. Creating that table is surprisingly expensive. I'll have it back later today, probably not including users who are not active. Should be good now. |
|
|
|
fireduck,
homepage does not show users/addresses anymore... ?
spiccioli
I know, I was having some database load issues. Creating that table is surprisingly expensive. I'll have it back later today, probably not including users who are not active. |
|
|
|
I wonder if there is any interest in people mining over tor.
If that is what you are into: stratum+tcp://zy2e3jz56abvdndx.onion:3333/ Seems to just work with torify wrapper: torify /home/pi/cgminer/bin/cgminer -o stratum+tcp://zy2e3jz56abvdndx.onion:3333/ -u 1FdKhHttWiwq6Wip1BBJG1f6ffD8pWYFiE_64 -p z |
|
|
|
|
For people with firewall issues, HHTT now has alternative stratum ports:
stratum+tcp://stratum.hhtt.1209k.com:3333/
stratum+tcp://stratum.hhtt.1209k.com:443/
stratum+tcp://stratum.hhtt.1209k.com:80/
I wonder if there is any interest in people mining over tor.
|
|
|
|
Just waiting for BFL to deliver...  Me too. I do need to get more power in my computer room first though. |
|
|
|
I'd say, find a way for a user to set a payout level  maybe 1address_difficulty_payoutLevel ? spiccioli The problem with that is if multiple shares disagree, it isn't clear what to do. I've added a payout at 1.0 BTC regardless of timing. |
|
|
|
There is a 66 GH user now... 66... maybe it is an Avalon unit It is using difficulty 128, though, which is rather low for such a big hashing power. spiccioli I have reason to believe it is exactly that. Seems to be working well. Given the big numbers these things throw up for now, I'm thinking I should add a line to the payout logic which pays out if more than 1 BTC is owed rather than waiting 24 hours. |
|
|
|
|
Pool has been spotty for the last hour. I was upgrading the database schema again.
Now SockThing (the stratum pool software) saves share data into AWS Simple Notification Service which in turns queues them in Simple Queue Service. This way the share data can build up in SQS in the event of a database outage or slow down.
|
|
|
|
So a share is considered "quite stale" if it is from a job at least two blocks behind. This should make it very rare unless you miner is ignoring the clear=true of the new jobs. I very much doubt that is happening.
I have code in to call shares from recent jobs "slightly stale" and still pay on them but I've never seen that happen so I'm guessing I have a bug in that code.
Found the bug, I had some logic inverted: https://github.com/fireduck64/SockThing/commit/acc07a8ef3d407c45afd9570807516aac6a896edStales should now show up as "slightly stale" and be paid correctly. |
|
|
|
|
So a share is considered "quite stale" if it is from a job at least two blocks behind. This should make it very rare unless you miner is ignoring the clear=true of the new jobs. I very much doubt that is happening.
I have code in to call shares from recent jobs "slightly stale" and still pay on them but I've never seen that happen so I'm guessing I have a bug in that code.
|
|
|
|
|
As a cool new feature to give a little bonus to miners:
For any blocks found using the stratum protocol with HHTT, half of the transaction fees will be sent to the miner in the block coinbase transaction. This bonus goes to the miner who actually found the block.
|
|
|
|
Yes, that is why they were rejected. They should start with zeros and if they don't have enough zeros they are rejected as something your client should never have submitted. Now, this shouldn't happen. For this to happen there needs to be some misunderstanding between the client and the server about what data you should be hashing. I'm not sure what caused that. Anything I can do to help you debugging? I'm back on getwork for now, but can switch to stratum again if it helps. That, it would be great to have you on stratum. I'd like to see if it reoccurs. If it is what I suspect it might have been it should be fixed now. |
|
|
|
|
In case anyone was paying attention, HHTT just had a 30 minute outage as a database table change took longer than I thought it would.
I'm going to change the stratum server to save shares via SQS rather than a database so that the pool can stay up for an outage like this. In that case, it would just delay processing and payments for shares but not block solving and all the shares would eventually be counted correctly.
Sorry for the trouble.
|
|
|
|
Returned 50. Turns out it's really easy to mine testnet bitcoins. No kidding. I accidentally forgot I had my fpga miner on testnet an came home to 20,000 testnet BTC. I sent 10k to that faucet. If anyone else needs any, let me know. |
|
|
|
|
Show Posts
