Show Posts
|
Pages: [1]
|
Alrighty, I got a list of pools from #monero bot and from Monero announcement thread. Every single one (except closed-source Minergate of course) is running my code. And as I stated in my previous post: if you add up their reported hash rates then it would appear that majority of network hash rate is being managed with my pool software, with the rest being solo-mined as I haven't found a single pool NOT running my code. So why is this the case? I'll list some reasons that stand out: - Performance. The share-trust algorithm LucasJones and I designed is our solution to the share validation CPU load problem that cryptonote hashing causes.
- Scalability. All functions of the pool are separate modules that can easily be horizontally scaled. And the pool clustering feature using Node.js tech is just about the most efficient way to use all CPU cores for this kind of software.
- A new TCP (stratum-like) protocol we implemented as a big improvement to the old http protocol.
- Attack mitigation. IP banning, detection of various attacks.
- Easy of use. Thorough instructions/documentation on how to setup and manage pool.
- Accessory software. LucasJones implemented cryptonight hashing into CPUminer as part of this bounty. I created the easy-miner Windows GUI app so "your grandma could mine."
- Flexibility. The design of the software has allowed people to easily create their own unique, beautiful front-end designs.
- Support. Worked closely with a lot of pool ops on irc during the design of this pool and all its features. And still working them them today; giving them support and taking feedback on what features need implemented or improved upon.
Check out the repo readme for more technical details https://github.com/zone117x/node-cryptonote-poolSomething else quite important - everything I listed above is not theoretical. They are features thoroughly tested by the community pool ops and miners and running in production right now. I could call on pool ops to give testimonies but I don't think that is necessary. The fact that every single pool is running my code seems like enough evidence.
|
|
|
Looks like majority of Monero hash rate is running through my pool code at this point - a week after announcing my pool ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Every Monero pool (and every other cryptonote coin) I've seen is running my code. re: superresistant, An "EADDRINUSE" error implies you're trying to open a port that is already in use.
|
|
|
No problem ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Figured I'd make that announcement here once the pool was confirmed working by several pool ops.
|
|
|
Alright, as of today I declare the pool software developed by LucasJones and I in a tested, stable, and working state: https://github.com/zone117x/node-cryptonote-poolThe three important features of a pool were all officially working about two days ago: 1) Share distribution and management , 2) Block solving, and 3) Paying out miners. And as of today several pool ops running our software have confirmed it is working. On top of building the basic pool that the bounty calls for: we have implemented many other extra, important pool features which are listed here: https://github.com/zone117x/node-cryptonote-pool#featuresI'll quote the features here as well: - IP banning to prevent low-diff share attacks
- Socket flooding detection
- Payment processing (with splintered transactions to deal with max transaction size)
- Detailed logging
- Ability to configure multiple ports - each with their own difficulty
- Variable difficulty / share limiter
- Share trust algorithm to reduce share validation hashing CPU load
- Clustering for vertical scaling
- Modular components for horizontal scaling (pool server, database, stats/API, payment processing, front-end)
- Live stats API (using CORS with AJAX and HTML5 EventSource)
- Currency network/block difficulty
- Current block height
- Network hashrate
- Pool hashrate
- Each miners' individual stats (hashrate, shares submitted, total paid, etc)
- Blocks found (pending, confirmed, and orphaned)
- An easily extendable, responsive, light-weight front-end using API to display data
- Worker login validation (make sure miners are using proper wallet addresses for mining)
The github readme has fully detailed instructions on pool usage as well as other useful instructions/information. LucasJones has also implemented Cryptonight mining into CPUMiner ( https://github.com/LucasJones/cpuminer-multi) which is another huge contribution to the community as reliance on simpleminer is a bad position to be in. I have also built a noob-friendly Windows app to help Windows user's start mining by simply downloading and clicking "start". The pool front-end links to it on the "getting started" page, and pool ops can easily configure the app to automatically mine on their pool once downloaded and ran. Here it is on github: https://github.com/zone117x/cryptonote-easy-minerLucasJones and I claim first working and verified pool server - along with many additional tools and features along with it. The pool server and other tools are also still in development as we believe in this community & technology, and would like to continue improving these tools to help facilitate the adoption of this technology.
|
|
|
Patience everyone ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) The coin source is obfuscated and its taking really smart C guys to figure out what's going on. The pool seems very close to being ready.
|
|
|
Eligius does it too right? They don't guarantee it 100% of the time but most payments are made that way.
EDIT: To clarify how this works, the miners who contribute to mining a block don't necessarily get paid from that block, their shares get credited like any other pool and upon reaching a minimum payment threshold their eventual payments are made using some future block's coinbase. That avoids the issues p2pool has with dust payouts vs. minimum share value.
Right - that works for big pools that find blocks often. If you aren't a huge pool then payment variance (or just payment waiting period) would not make miners happy :p Latest code should be working very well with vardiff and share acceptance. Payment processing and IP banning to mitigate low-diff share attacks is under development. Right now I'm stuck on getting address validation. Looks like it should be: slice off 4 byte checksum -> decode rest as varint -> keccak (w/ 64 byte output ??) -> compare result to checksum.
|
|
|
Yes the code is there to submit blocks when found although I haven't been able to test it. Assuming the documentation on bytecoin wiki is correct blocks should be submitted to daemon correctly.
I'm still developing payment processing so I'll have to setup a testnet of sorts somehow to test it all out.
|
|
|
Smooth, Lucas said he fixed the compiling issues with node-multi-hashing so give it another try.
Also regarding the payments in coinbase talk. That isn't practical to do with a normal Bitcoin-based pool for a few reasons - and there are even more reasons why its not practical to do with this new cryptocurrency. Its what p2pool does and it's part of the reason p2pool has its drawbacks compared to a central mining pool.
|
|
|
Thanks for the error log perl I'll look into it. Part of the problem is this crappy old get-work like protocol we have to work with. Smooth someone else said they are having issues getting node-multi-hashing to compile. Not sure why its not working for some people - but I'm looking into it. Also not sure why you had that much trouble getting Node.js working - did you follow these instructions? https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager#ubuntu-mint-elementary-osBtw my guy looks like he has stratum protocol with cryptonight almost working with CPUMiner: https://github.com/LucasJones/cpuminer-multi/commits/masterLooking like I'll be able to deliver you to you guys not only a pool for simpleminer, but also a stratum pool and cryptonote version of CPUMiner (stratum / multi-core) ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
Smooth - looks like your system is lacking ability to compile the C modules. You need some dependencies installed. From https://www.npmjs.org/package/node-gypOn Unix: python (v2.7 recommended, v3.x.x is not supported) make A proper C/C++ compiler toolchain, like GCC
|
|
|
https://github.com/zone117x/node-cryptonote-poolStuff that is working: - Share validation
- Node.js clustering for pool performance
- Variable difficulty
- Long polling
- Configurable pool difficulty and vardiff
- Detailed logging with configurable log levels (debug, warn, error) and colorful log styling
- Storing shares in redis per miner
- Storing hashrate data
- Submitting and recording solved blocks
- Misc. configurable options: worker timeouts, block polling interval, pool threads
- Documentation (installation and usage instructions)
Stuff that is left: - Payment processor (checks for confirmed blocks then payouts according to shares)
- AJAX/REST API to display stats (hashrates, payouts, coin network info, etc)
- Light-weight front-end which uses API to display stats
The stuff left are the easy parts. ETA for all of the above is 24-48 hours of this point. Feel free to test it out: https://github.com/zone117x/node-cryptonote-pool#usage
|
|
|
Sorry for the delayed reply.. Be sure to read the setup/require instructions in the readme. One of the commands is Which fetches all modules/dependencies. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
Hi Tersken, You need to provide much more information if you want help debugging. Open an issue on github and provide as many details as you can - especially your configuration and error stack trace.
|
|
|
clevermining.com is in the process of integrating it into their system - not sure where they are at on that. It may or may not be running live on there at this point. Other than that, people have implied that they have been running it live but have not disclosed their pool to me. The project is still fairly new - but in time I expect to add a list to the README of pools running it live ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
Can you give me some more detail? If it was a problem with the x11 hashing then you would be seeing low-difficulty shares most likely. Workers not being able to connect sounds like you just have a configuration problem.
|
|
|
Open source: https://github.com/zone117x/node-stratumHigh performance Stratum poolserver in Node.js. One instance of this software can startup and manage multiple coin pools, each with their own daemon and stratum port ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) This project does not do any payment processing. For a full featured portal that uses this module, see NOMP (Node Open Mining Portal). It handles payments, website front-end, database layer, mutli-coin/pool support, auto-switching miners between coins/pools, etc.. The portal also has an MPOS compatibility mode so that the it can function as a drop-in-replacement for python-stratum-mining. Features- Daemon RPC interface
- Stratum TCP socket server
- Block template / job manager
- Optimized generation transaction building
- Connecting to multiple daemons for redundancy
- Process share submissions
- Session managing for purging DDoS/flood initiated zombie workers
- Auto ban IPs that are flooding with invalid shares
- POW (proof-of-work) & POS (proof-of-stake) support
- Transaction messages support
- Vardiff (variable difficulty / share limiter)
- When started with a coin deamon that hasn't finished syncing to the network it shows the blockchain download progress and initializes once synced
- Supports algorithms:
- SHA256 (Bitcoin, Freicoin, Peercoin/PPCoin, Terracoin, etc..)
- Scrypt (Litecoin, Dogecoin, Feathercoin, etc..)
- Scrypt-Jane (YaCoin, CopperBars, Pennies, Tickets, etc..)
- Scrypt-N (YaCoin, CopperBars, Pennies, Tickets, etc..)
- Quark (Quarkcoin [QRK])
- X11 (Darkcoin [DRK])
Example usage: Create the configuration for your coin: var myCoin = { "name": "Dogecoin", "symbol": "DOGE", "algorithm": "scrypt", //or "sha256", "scrypt-jane", "scrypt-n", "quark", "x11" "txMessages": false, //or true (not required, defaults to false) };
If you are using the `scrypt-jane` algorithm there are additional configurations: var myCoin = { "name": "Freecoin", "symbol": "FEC", "algorithm": "scrypt-jane", "chainStartTime": 1375801200, //defaults to 1367991200 (YACoin) if not used "nMin": 6, //defaults to 4 if not used "nMax": 32 //defaults to 30 if not used };
If you are using the `scrypt-n` algorithm there is an additional configuration: var myCoin = { "name": "Execoin", "symbol": "EXE", "algorithm": "scrypt-n", /* This defaults to Vertcoin's timetable if not used. It is required for scrypt-n coins that have modified their N-factor timetable to be different than Vertcoin's. */ "timeTable": { "2048": 1390959880, "4096": 1438295269, "8192": 1485630658, "16384": 1532966047, "32768": 1580301436, "65536": 1627636825, "131072": 1674972214, "262144": 1722307603 } };
Create and start new pool with configuration options and authentication function var Stratum = require('stratum-pool');
var pool = Stratum.createPool({
"coin": myCoin,
"address": "mi4iBXbBsydtcc5yFmsff2zCFVX4XG7qJc", //Address to where block rewards are given "blockRefreshInterval": 1000, //How often to poll RPC daemons for new blocks, in milliseconds
/* How many milliseconds should have passed before new block transactions will trigger a new job broadcast. */ "txRefreshInterval": 20000,
/* Some miner software is bugged and will consider the pool offline if it doesn't receive anything for around a minute, so every time we broadcast jobs, set a timeout to rebroadcast in this many seconds unless we find a new job. Set to zero or remove to disable this. */ "jobRebroadcastTimeout": 55,
//instanceId: 37, //Recommend not using this because a crypto-random one will be generated
/* Some attackers will create thousands of workers that use up all available socket connections, usually the workers are zombies and don't submit shares after connecting. This features detects those and disconnects them. */ "connectionTimeout": 600, //Remove workers that haven't been in contact for this many seconds
/* If a worker is submitting a good deal of invalid shares we can temporarily ban them to reduce system/network load. Also useful to fight against flooding attacks. */ "banning": { "enabled": true, "time": 600, //How many seconds to ban worker for "invalidPercent": 50, //What percent of invalid shares triggers ban "checkThreshold": 500, //Check invalid percent when this many shares have been submitted "purgeInterval": 300 //Every this many seconds clear out the list of old bans },
/* Each pool can have as many ports for your miners to connect to as you wish. Each port can be configured to use its own pool difficulty and variable difficulty settings. varDiff is optional and will only be used for the ports you configure it for. */ "ports": { "3032": { //A port for your miners to connect to "diff": 32, //the pool difficulty for this port
/* Variable difficulty is a feature that will automatically adjust difficulty for individual miners based on their hashrate in order to lower networking overhead */ "varDiff": { "minDiff": 8, //Minimum difficulty "maxDiff": 512, //Network difficulty will be used if it is lower than this "targetTime": 15, //Try to get 1 share per this many seconds "retargetTime": 90, //Check to see if we should retarget every this many seconds "variancePercent": 30 //Allow time to very this % from target without retargeting } }, "3256": { //Another port for your miners to connect to, this port does not use varDiff "diff": 256 //The pool difficulty } },
/* Recommended to have at least two daemon instances running in case one drops out-of-sync or offline. For redundancy, all instances will be polled for block/transaction updates and be used for submitting blocks. Creating a backup daemon involves spawning a daemon using the "-datadir=/backup" argument which creates a new daemon instance with it's own RPC config. For more info on this see: - https://en.bitcoin.it/wiki/Data_directory - https://en.bitcoin.it/wiki/Running_bitcoind */ "daemons": [ { //Main daemon instance "host": "localhost", "port": 19332, "user": "litecoinrpc", "password": "testnet" }, { //Backup daemon instance "host": "localhost", "port": 19344, "user": "litecoinrpc", "password": "testnet" } ],
/* This allows the pool to connect to the daemon as a node peer to recieve block updates. It may be the most efficient way to get block updates (faster than polling, less intensive than blocknotify script). However its still under development (not yet working). */ "p2p": { "enabled": false, "host": "localhost", "port": 19333,
/* Magic value is different for main/testnet and for each coin. It is found in the daemon source code as the pchMessageStart variable. For example, litecoin mainnet magic: http://git.io/Bi8YFw And for litecoin testnet magic: http://git.io/NXBYJA */ "magic": "fcc1b7dc",
//Found in src as the PROTOCOL_VERSION variable, for example: http://git.io/KjuCrw "protocolVersion": 70002, }
}, function(ip, workerName, password, callback){ //stratum authorization function console.log("Authorize " + workerName + ":" + password + "@" + ip); callback({ error: null, authorized: true, disconnect: false }); });
Listen to pool events /* 'data' object contains: job: 4, //stratum work job ID ip: '71.33.19.37', //ip address of client worker: 'matt.worker1', //stratum worker name difficulty: 64, //stratum client difficulty reward: 5000000000, //the number of satoshis received as payment for solving this block height: 443795, //block height networkDifficulty: 3349 //network difficulty for this block
//solution is set if block was found solution: '110c0447171ad819dd181216d5d80f41e9218e25d833a2789cb8ba289a52eee4',
//tx is the coinbase transaction hash from the block tx: '41bb22d6cc409f9c0bae2c39cecd2b3e3e1be213754f23d12c5d6d2003d59b1d,
error: 'low share difficulty' //set if share is rejected for some reason */ pool.on('share', function(isValidShare, isValidBlock, data){
if (isValidBlock) console.log('Block found'); else if (isValidShare) console.log('Valid share submitted'); else if (data.solution) console.log('We thought a block solution was found but it was rejected by the daemon'); else console.log('Invalid share submitted')
console.log('share data: ' + JSON.stringify(data)); });
/* 'severity': can be 'debug', 'warning', 'error' 'logKey': can be 'system' or 'client' indicating if the error was caused by our system or a stratum client */ pool.on('log', function(severity, logKey, logText){ console.log(severity + ': ' + '[' + logKey + '] ' + logText); });
Start pool
|
|
|
|