Sure, not a problem, want directions with that?
BAM: https://bitcointa.lk/threads/how-to-start-your-own-mining-pool-using-bitcoind-eloipool.272362/
Topic: Using eloipool with litecoind (Read 5382 times)
thanks for posting this link
Cheers, I got this working: https://github.com/CryptoManiac/eloipool-scrypt
But my princess is in another castle. 
But my princess is in another castle. 
I have been testing around with https://github.com/moopless/stratum-mining-litecoin.git
Support vardiff and stratum from the box, and was very easy to get running. Dunno about performance tho, only have ran it with 1-2 users. Getting mmcfe run the way you want is the 'B'.
Support vardiff and stratum from the box, and was very easy to get running. Dunno about performance tho, only have ran it with 1-2 users. Getting mmcfe run the way you want is the 'B'.
Who knows why the link is not working?
I have been testing around with https://github.com/moopless/stratum-mining-litecoin.git
Support vardiff and stratum from the box, and was very easy to get running. Dunno about performance tho, only have ran it with 1-2 users. Getting mmcfe run the way you want is the 'B'.
Support vardiff and stratum from the box, and was very easy to get running. Dunno about performance tho, only have ran it with 1-2 users. Getting mmcfe run the way you want is the 'B'.
This solution is 100% working?
Someone found a solution which allows eloipool to work with litcoin?
I can not believe that this is an impossible task!
I can not believe that this is an impossible task!
I'm currently trying to get this implemented as well. I bypassed the failing tests for the moment, and the program seems to startup and listen for connections, but when trying to connect to the stratum port I get:
AttributeError: 'StratumServer' object has no attribute 'JobBytes'
Continuing to dig into it.
AttributeError: 'StratumServer' object has no attribute 'JobBytes'
Continuing to dig into it.
I tried it, can't get it to work.
I'm currently hung up on the following error:
Traceback (most recent call last):
File "./eloipool.py", line 80, in
from bitcoin.txn import Txn
File "/home/ltc/eloipool-litecoin/bitcoin/txn.py", line 146, in
_test()
File "/home/ltc/eloipool-litecoin/bitcoin/txn.py", line 124, in _test
assert t.txid == b"C\xeczW\x9fUa\xa4*~\x967\xadAVg'5\xa6X\xbe'R\x18\x18\x01\xf7#\xba3\x16\xd2"
AssertionError
Using blocknotify for pushpool I set blocknotify to run this script:
I seem to find more uses for blocknotify in every project I am working on...
This variant is acceptable only if pushpoold and bitcoind runned by the same account. Configurations like this not recommended for security reasons.Code:
#!/usr/bin/env python
import sys
import os
os.system("killall -s SIGUSR1 pushpoold")
I seem to find more uses for blocknotify in every project I am working on...
The preferred option is:
1) run litecoind and pushpoold using separated accounts (I usually using accounts named like "litecoin" and "pushpool")
2) simple C program for notify event handling:
Code:
#include
int main(void)
{
system("ps -ef | grep pushpoold | grep -v grep | awk '{print $2}' | xargs kill -s SIGUSR1 > /dev/null 2> /dev/null");
return 0;
}
Code:
gcc -o blocknotify blocknotify.c
chown pushpool:pushpool ./blocknotify
chmod ug+s ./blocknotify
Code:
blocknotify='/opt/blocknotify'
Like the origin, alexhz's fork uses 10s timer and SIGUSR1 as a trigger events to request new work template from upstream. Litecoind has getworkex integrated, so this daemon can work with unpatched litecoind, but blknotify script is required.
I also found this simple little block monitor quite useful:
-blknotify option will be simplier and more reliable.You are 100% correct. I have been using the blocknotify option for a number of things, including some experiments with the explorers and tripping database updates..
Using blocknotify for pushpool I set blocknotify to run this script:
Code:
#!/usr/bin/env python
import sys
import os
os.system("killall -s SIGUSR1 pushpoold")
I seem to find more uses for blocknotify in every project I am working on...
Balthazar, got that code for me ? Still looking for vardiff code
Oh, I'm sorry because I forget about it. 
But I found the sources, and can send it to you. Give me your e-mail in PM. 
Balthazar, got that code for me ? Still looking for vardiff code
OP, can you please reply to my PM's ?
Thanks.
Thanks.
It's quite simple, and I have implementation of this feature for btc. I'll try to find my sources tomorrow.
Thanks a lot, I've got the block monitor script up an running, it willingly sends the signal when a new block is found on the network.
blkmon was doing nothing :-/
Where in the code is difficulty defined ? All I see is EASY_TARGET in config.c .. Which is
in original code.
Would that need to be defined for each worker separately ?
blkmon was doing nothing :-/
Where in the code is difficulty defined ? All I see is EASY_TARGET in config.c .. Which is
Code:
define EASY_TARGET "fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff00000"
in original code.
Would that need to be defined for each worker separately ?
Like the origin, alexhz's fork uses 10s timer and SIGUSR1 as a trigger events to request new work template from upstream. Litecoind has getworkex integrated, so this daemon can work with unpatched litecoind, but blknotify script is required.
I also found this simple little block monitor quite useful:
-blknotify option will be simplier and more reliable.
I do not know of a patch, but variable difficulty is one of the things I have looked in to.
It did not appear that it would be that hard to implement.
I was thinking of a non-registered login where miners would use whatever payout address they want as the username and the password would be the difficulty the miner wanted.Perhaps coded like Bitparking pools (d=xx) anything else in the password field would just be ignored.
In the sever.c code it is fairly easy to find and enable/disable the password/username check and/or add whatever code you wanted to run at miner login.
Perhaps a check to make sure the address is a valid address for the chain, then place the payout address in the pool_worker database along with the password(difficulty desired).
One could just as easy use a registered system and add a difficulty field to the pool_worker table.
Either way, the simplicity of the pushpool code, makes alterations easier then with some of the newer pool software.
Quick hint: if using the native blkmond for long poll trips, there are two places in the blkmond code that directly contain and use the "magic" number for the chain:
I sometimes think that the pool software developers purposely bury things like "magic numbers" instead of having them defined in the config file in order to make it more of a "challenge" to adapt the software to other coins..
Some of the new daemons have a block notify feature that could be used to completely remove the need for a complex block monitor.
I also found this simple little block monitor quite useful:
Thanks to metonymous
Bitcointalk thread:
https://bitcointalksearch.org/topic/blkmond-lite-8797
It did not appear that it would be that hard to implement.
I was thinking of a non-registered login where miners would use whatever payout address they want as the username and the password would be the difficulty the miner wanted.Perhaps coded like Bitparking pools (d=xx) anything else in the password field would just be ignored.
In the sever.c code it is fairly easy to find and enable/disable the password/username check and/or add whatever code you wanted to run at miner login.
Code:
/* password database authentication check */
pass_db = pwdb_lookup(user);
if (!pass_db || (strcmp(pass, pass_db) && *pass_db != '\0'))
goto out;
rc = true;
strncpy(username_out, user, 64);
username_out[64] = 0;
out:
free(pass_db);
free(bin);
free(t_type);
free(t_b64);
free(t_userpass);
return rc;
One could just as easy use a registered system and add a difficulty field to the pool_worker table.
Either way, the simplicity of the pushpool code, makes alterations easier then with some of the newer pool software.
Quick hint: if using the native blkmond for long poll trips, there are two places in the blkmond code that directly contain and use the "magic" number for the chain:
Code:
def got_data(self):
while True:
if len(self.recvbuf) < 4:
return
if self.recvbuf[:4] != "\xFC\xC1\xB7\xDC":
raise ValueError("got garbage %s" % repr(self.recvbuf))
if self.ver_recv < 209:
if len(self.recvbuf) < 4 + 12 + 4:
return
Code:
def send_message(self, message, pushbuf=False):
if self.state != "connected" and not pushbuf:
return
print "send %s" % repr(message)
command = message.command
data = message.serialize()
tmsg = "\xFC\xC1\xB7\xDC"
tmsg += command
tmsg += "\x00" * (12 - len(command))
tmsg += struct.pack("
I sometimes think that the pool software developers purposely bury things like "magic numbers" instead of having them defined in the config file in order to make it more of a "challenge" to adapt the software to other coins..
Some of the new daemons have a block notify feature that could be used to completely remove the need for a complex block monitor.
I also found this simple little block monitor quite useful:
Code:
#!/usr/bin/env python
from jsonrpc.authproxy import AuthServiceProxy
import sys
import os
access = AuthServiceProxy("http://RPCUSER:[email protected]:8332")
blockcount = access.getblockcount()
from time import sleep
while(True):
newcount = access.getblockcount()
if newcount > blockcount:
os.system("killall -s SIGUSR1 pushpoold")
sys.stdout.write("B")
sys.stdout.flush()
blockcount = newcount
sleep(1)
else:
sleep(0.1)
Bitcointalk thread:
https://bitcointalksearch.org/topic/blkmond-lite-8797
Jump to: