[Dev] Feathercoin - P2Pool-Neoscrypt - Now Available
-
Lizhi, the errors regarding webroot.putchild are normal as long as no other p2pool node has a worker connected. It simply can’t determine the global pool hash rate.
To give an update on my tests:
-
neoscrypt module for p2pool installed in python with profile 0
-
used ghostlanders neoscrypt p2pool as basis and added the feathercoin infos in networks.py and bitcoin/networks.py
-
forced the pool to use getblocktemplate, as suggested by ghostlander
-
current log shows:
2014-08-05 19:06:05.383892 Worker mrKP5thmnTRxV2Em8x3d8pamPXWHtv2Ed submitted share with hash > target:
2014-08-05 19:06:05.384129 Hash: 67146109f860500455e07f9c06a298ec2bd85202c42c18bd0bd63bf0cb059a5e
2014-08-05 19:06:05.384219 Target: a6c64b37894160e5d022dbf97e6abc74931804560e2db29defa7c64b378941 -
implemented reversebyte to change from big endian to little endian for target.
this changes the target, but as the Pow_hash has 2 bytes more than the target, it is always bigger than the target.
I noticed, that Ghoslander has aa pcx p2pool running on his testnet, which is on neoscrypt, so I send him a message to ask what he has modified to get it running.
-
-
new commit on github, including reversebyte.py, which was missing.
Still not working
-
Great work guys!
-
oh, it not work :-
-
I spend half a day on the p2pool stuff again
no results
what I noticed is, that the p2pool neoscrypt module produces wrong results while the same code runs fine in the wallet, so it may be ‘just’ a problem of function calls and parameter transfer between python and C++.also if I read it right, the Wallet code passes variables to the neoscrypt procedure, as in GetPowHash() in main.h, while the python passes pointer to structures??
Eample from wallet main.h:
/* Calculates block proof-of-work hash using either NeoScrypt or Scrypt */ uint256 GetPoWHash() const { unsigned int profile = 0x0; uint256 hash; /* All blocks generated up to this time point are Scrypt only */ if((fTestNet && (nTime < nTestnetSwitchV2)) || (!fTestNet && (nTime < nSwitchV2))) { profile = 0x3; } else { /* All these blocks must be v2+ with valid nHeight */ int nHeight = GetBlockHeight(); if(fTestNet) { if(nHeight < nTestnetFork) profile = 0x3; } else { if(nHeight < nForkFour) profile = 0x3; } } neoscrypt((unsigned char *) &nVersion, (unsigned char *) &hash, profile); return hash; }
Example from p2pool/work.py:
pow_hash = self.node.net.PARENT.POW_FUNC(bitcoin_data.block_header_type.pack(header))
Where header is a dict in python.
-
Wellen,
I’m at the same point as you now :(
I get everything looking like it’s running well but nothing is accepted by the wallet, I’ll keep pluggin away but I’m some what in the dark here as my coding skills are limited in this area :(
UM
-
The miner says ’ hash accepted’ , but in the p2pool log you will see entries like ‘worker xyz submitted share with hash > target’
-
I spend half a day on the p2pool stuff again
no results
what I noticed is, that the p2pool neoscrypt module produces wrong results while the same code runs fine in the wallet, so it may be ‘just’ a problem of function calls and parameter transfer between python and C++.also if I read it right, the Wallet code passes variables to the neoscrypt procedure, as in GetPowHash() in main.h, while the python passes pointer to structures??
Eample from wallet main.h:
/* Calculates block proof-of-work hash using either NeoScrypt or Scrypt */ uint256 GetPoWHash() const { unsigned int profile = 0x0; uint256 hash; /* All blocks generated up to this time point are Scrypt only */ if((fTestNet && (nTime < nTestnetSwitchV2)) || (!fTestNet && (nTime < nSwitchV2))) { profile = 0x3; } else { /* All these blocks must be v2+ with valid nHeight */ int nHeight = GetBlockHeight(); if(fTestNet) { if(nHeight < nTestnetFork) profile = 0x3; } else { if(nHeight < nForkFour) profile = 0x3; } } neoscrypt((unsigned char *) &nVersion, (unsigned char *) &hash, profile); return hash; }
Example from p2pool/work.py:
pow_hash = self.node.net.PARENT.POW_FUNC(bitcoin_data.block_header_type.pack(header))
Where header is a dict in python.
I think it is in main.py.
if share.pow_hash
-
For testing I temporarily modified the neoscrypt.c of the p2pool neoscrypt module and defined the input value of the hashing procedure as constant in the c-code. It seems to calculate correctly.
Also the target on p2pool measured against seems to be fine.
I assume, that the return value from the neoscrypt module either has an overflow or is interpreted wrong. may be wrong type, little/big endian problem or whatever.
------------- Edit---------------
Checked type of pow_hash and target in work.py -> both variables have type ‘long’
-
If you switch CPUminer in debug mode with -D, you can see P2Pool asking for incorrect targets:
[2014-08-10 21:21:12] 1 miner threads started, using 'neoscrypt' algorithm. [2014-08-10 21:21:15] Long-polling activated for http://prometheus.phoenixcoin.org:20554/long-polling [2014-08-10 21:21:15] DEBUG: got new work in 3062 ms [2014-08-10 21:21:16] DEBUG (little endian): hash
-
It is working now for long-poll.
No support for stratum at the moment, even if work is distributed, no valid blocks can be mined via stratum.
A new version is on github
-
Yes, It work! >:D
-
neoscrypt p2pool dev testing cpu mine phoenixcoin
Longpoll works, so start minerd with ‘–no-stratum’
useing Ghostlander’s Github (for minerd)
-
Latest code pushed
git clone git://github.com/wellenreiter01/p2pool-neoscrypt
-
What is the status of the p2pool?
Is there still a problem with stratum?
Are we near to pushing some changes upstream? How far back can that go?
That makes things easier running multicoin p2pools. That will mean the “central p2pool” distribution gets updated.
-
Stratum suport still is not implemented, but longpoll runs stable, so this is not a show stopper for pooled neoscrypt mining.
Due to the fact, that neoscrypt uses little endian data only, while other algorithms use big endian encoding, neoscrypt p2pool is not compatible with non-neoscrypt coins.
Therefore two different versions of p2pool will exist in the futute, unless significant changes in the code is done to implement coin dependent encoding of data. These changes would need a couple of if-then clauses reducing the speed of p2pool operation, and/or increasing the load put un the underlaying host system.
Another solutution would be to adapt neoscrypt to the big endian encoding used for other algorithms, but this would mean another hard fork for any coin productive with neoscrypt.
-
Update:
Stratum support works for minerd.
It can be testet on
-
http://p2pool.neoscrypt.de:10554 ( German pool )
-
http://pool20.neoscrypt.de:10554 ( Dutch pool )
GPU miner adaption is ongoing, but not working yet
-
-
Yay!!!
http://pool.ftc-c.com:19328 (china pool ) :)
Stratum support works for minerd.
CGminer Command Line:
cgminer.exe --neoscrypt --worksize 256,256,256 --thread-concurrency 8960,8960,4000 -I 12,12,12 -g 1 -o stratum+tcp://pool.ftc-c.com:19328 -u TRsuTqxAMKZNvC7JzGNgvM49rkQNcxqjhi -p x
-
Update:
Thanks to the help of Avehre, p2pool now fully supports stratum for cpuminer and gpuminer. ;D O0 8)
Latest Version is on github.
p2pool.neoscrypt.de:10554 (46.4.0.101:10554) is already updated and supporting stratum for gpuminer
pool20.neoscrypt.de:10554 (95.85.58.10:10554) will be updated soon.
Please be aware, that you also need the latest beta-Version of gpuminer to use stratum successfully
-
Another solution would be to adapt neoscrypt to the big endian encoding used for other algorithms, but this would mean another hard fork for any coin productive with neoscrypt.
This is actually a good idea to consider for the Feathercoin implementation of neoscrypt - as it would mean pxc and ftc don’t end up like ltc and ftc with scrypt. e.g. big player coin switch over attacks …
It won’t be a hard fork, because ftc hasn’t implemented it. i.e. with some thought it might be possible to retain each format as an option (without too much work).
Additional advantages would be -
It would be possible to have different “colours of neoscrypt” for different coins to use so ASICS are harder (e.g. switchable).
pxc or ftc would have an easy switch mechanism to extend ASIC avoidance.