$ minerd -o 127.0.0.1:<rpc port, default=18121> -u <user> -p <password> -t <threads, such as 2>new - Solo - https://github.com/mikeghen/litecoin-solo-mining-tutorialvar myCoin = {
"name": "Goldcoin",
"symbol": "GLD",
"algorithm": "scrypt",
"peerMagic": "fdc2b4dd",
"peerMagicTestnet": "fcc5b4dd"
};
var Stratum = require('stratum-pool');
var pool = Stratum.createPool({
"coin": myCoin,
"auxes": [],
"address": "n33ZW9SXvtCXRvsP7gjQqYFaEwxwpXoWpC", //Address to where block rewards are given
/* Block rewards go to the configured pool wallet address to later be paid out to miners,
except for a percentage that can go to, for examples, pool operator(s) as pool fees or
or to donations address. Addresses or hashed public keys can be used. Here is an example
of rewards going to the main pool op, a pool co-owner, and NOMP donation. */
// "rewardRecipients": {
// "n37vuNFkXfk15uFnGoVyHZ6PYQxppD3QqK": 1.5, //1.5% goes to pool op
// "mirj3LtZxbSTharhtXvotqtJXUY7ki5qfx": 0.5, //0.5% goes to a pool co-owner
// },
"blockRefreshInterval": 1000, //How often to poll RPC daemons for new blocks, in milliseconds
/* Some miner apps will consider the pool dead/offline if it doesn't receive anything new jobs
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,
/* 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": 1200, //Remove workers that haven't been in contact for this many seconds
/* Sometimes you want the block hashes even for shares that aren't block candidates. */
"emitInvalidBlockHashes": false,
/* Enable for client IP addresses to be detected when using a load balancer with TCP proxy
protocol enabled, such as HAProxy with 'send-proxy' param:
http://haproxy.1wt.eu/download/1.5/doc/configuration.txt */
"tcpProxyProtocol": false,
/* If a worker is submitting a high threshold of invalid shares we can temporarily ban their IP
to reduce system/network load. Also useful to fight against flooding attacks. If running
behind something like HAProxy be sure to enable 'tcpProxyProtocol', otherwise you'll end up
banning your own IP address (and therefore all workers). */
"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": {
"3333": { //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": "127.0.0.1",
"port": 19332,
"user": "Stouse49",
"password": "x"
}
// { //Backup daemon instance
// "host": "127.0.0.1",
// "port": 19344,
// "user": "litecoinrpc",
// "password": "testnet"
// }
],
/* This allows the pool to connect to the daemon as a node peer to receive block updates.
It may be the most efficient way to get block updates (faster than polling, less
intensive than blocknotify script). It requires the additional field "peerMagic" in
the coin config. */
"p2p": {
"enabled": false,
/* Host for daemon */
"host": "127.0.0.1",
/* Port configured for daemon (this is the actual peer port not RPC port) */
"port": 18121,
/* If your coin daemon is new enough (i.e. not a [beep]coin) then it will support a p2p
feature that prevents the daemon from spamming our peer node with unnecessary
transaction data. Assume its supported but if you have problems try disabling it. */
"disableTransactions": true
}
}, function(ip, port , workerName, password, callback){ //stratum authorization function
console.log("Authorize " + workerName + ":" + password + "@" + ip);
callback({
error: null,
authorized: true,
disconnect: false
});
});
pool.on('share', function(isValidShare, isValidBlock, data){
if (isValidBlock)
console.log('Block found');
else if (isValidShare)
console.log('Valid share submitted');
else if (data.blockHash)
console.log('We thought a block was found but it was rejected by the daemon');
else
console.log('Invalid share submitted')
console.log('share data: ' + JSON.stringify(data));
});
pool.on('log', function(severity, logKey, logText){
console.log(severity + ': ' + '[' + logKey + '] ' + logText);
});
console.log("Starting Pool")
pool.start();
console.log("Pool started", pool)
Problem.You should not modify the scripts provided in the zip file I think, just follow the instructions from the first post.
Goldcoin 0.7.5 TestNet Mining with cpuminer (slow)
[2018-02-06 16:55:03] Binding thread 0 to cpu 0
[2018-02-06 16:55:03] Binding thread 1 to cpu 1
[2018-02-06 16:55:03] 4 miner threads started, using 'scrypt' algorithm.
[2018-02-06 16:55:03] Binding thread 2 to cpu 2
[2018-02-06 16:55:03] Binding thread 3 to cpu 3
[2018-02-06 16:55:03] No payout address provided, switching to getwork
[2018-02-06 16:55:04] thread 2: 4104 hashes, 17.51 khash/s
[2018-02-06 16:55:04] thread 3: 4104 hashes, 17.51 khash/sProblem.
Problem.
You are trying to mine with cpuminer and the new client.
This doesn't work and it only possible with the old client.
Yes, it does not work, too.
Update your new client here.Great, downloaded and running fine. Tested transactions between this and 0.7.5 client, no problem.
Paying a zero fee is just fine as long as there is free transaction space available in the blocks. But be aware that this can end up in a never confirming transaction if the demand for free transactions has exceeded 5% of the block capacity.
Would it make sense to relocate the "Send as zero fee transaction" box as shown, replacing the required fee box?
(https://www.goldcointalk.org/devteam/client_fees.jpg)
And then replace the tool tip message to read:QuotePaying a zero fee is just fine as long as there is free transaction space available in the blocks. But be aware that this can end up in a never confirming transaction if the demand for free transactions has exceeded 5% of the block capacity.
If we elect to go this route, we could just make .001 the minimum on the adjustable counter, since the only lower setting is zero anyway. This would force the user to choose between zero-fee via checkbox, or minimum or something higher via counter.
Additional note: We probably want the zero-fee transaction box to be clear by default, and after each client restart.
I think you will end up with a lot less headaches from user complaints (that their transaction didn't happen) as long as the user is forced to check the box for a free transaction. The location point is sort of moot, but others may disagree.
Design Positive Feedback:What is the warning?
- First time run popup warning to be smaller.
- Pending balance having an estimated time until its available balance.
- The word "label" to be replaced with "message" or "note"The word "label" is consistent with the Receive page and the File / Receiving addresses dialog. "message" is a different piece of information.
- "Subtract fee from amount" sentence needs to be moved a little bit to the rightWhat does the "Pay To:" field need to be symmetrical with? It currently has the same width as the Label field when considering the three buttons to its right.
- "Enter a Goldcoin address" box to be resized until it is symmetrical
- Once the "send as zero-fee transaction" box is ticked, the recommended and custom tickers/boxes get disabled (grayed out)The recommended and custom boxes still have value because they will apply if the transaction size is greater than 1 KB as those values will be used as the transaction fee. Transactions > 1 kb cannot be free, under the default rules.
- Remove hard to understand sentences (too much information going on at once) such as these:Will the casual user click the "Choose..." button to get more control over the transaction fee? Most of these fields apply to a coin like bitcoin, which has a congested network. We could simply hide all these extra fields unless they have non-default values based on transaction history. The smart fee system looks at the recent block history and the fees for the transactions and comes up with estimates for confirmation times and fees. In our testnet and in the goldcoin mainnet, there aren't enough transactions to trigger this to show recommended fees other than 0.001.
- "Smart fee not initialized yet, This usually takes a few blocks...)"
- Remove the part from the "confirmation time target" with only the time, no block amount, the block amount doesnt matter to the casual user.
These sentences create confusion and isn't important to the casual user, if you feel like having more information about that option replace the sentence with a simple "?" box where the user receives a popup where they can read more about that following option.If the user wants a simple experience, then the "Hide" button works well. Granted that most of the options in the transaction fees section are redundant and not necessary for a coin with a low transaction volume.
- Jeroen
I think you will end up with a lot less headaches from user complaints (that their transaction didn't happen) as long as the user is forced to check the box for a free transaction. The location point is sort of moot, but others may disagree.
The location isn't moot because it replaces a redundant line of operation within the client which then makes the custom settings less complex, easier to understand, and logical (while currently they are not). Eg. It's impossible for a "zero fee" and a "required fee" to exist simultaneously.
My recommendation is that we hide all the extra sliders and text if the recommended fee for a fast transaction confirmation is the same as the Required Fee (0.001).
Custom: per kilobyte: 0.001 (the minimum value here is same as the Required Fee, but this can be increased, but not lowered)
Required Fee: 0.001 (the minimum allowed by the client, if paying a fee) <-- This could be hidden if the Recommended Fee is the same as the Required Fee, other wise we could show it.
Send as Zero Fee: Will send as 0.000 fee, unless size > 1Kb, then uses the above fee. We could put a tool tip here regarding side effects of this.
Thanks for this feedback. We welcome pull requests for these changes!Design Positive Feedback:What is the warning?
- First time run popup warning to be smaller.
- Pending balance having an estimated time until its available balance.
Pending Balance - the time is always 1 block or about 2 minutes.- The word "label" to be replaced with "message" or "note"The word "label" is consistent with the Receive page and the File / Receiving addresses dialog. "message" is a different piece of information.
Consider the following request made from the Receive page , which is based on BIP21. Message and Label are separate fields.
Payment information
URI: goldcoin:muySJLBHA4JKz9cMKQbjCzySGoJtSTzP1z?amount=200.00000000&label=My%20Label&message=My%20longer%20message%20about%20this%20request
Address: muySJLBHA4JKz9cMKQbjCzySGoJtSTzP1z
Amount: 200.00000000 GLD
Label: My Label
Message: My longer message about this request- "Subtract fee from amount" sentence needs to be moved a little bit to the rightWhat does the "Pay To:" field need to be symmetrical with? It currently has the same width as the Label field when considering the three buttons to its right.
- "Enter a Goldcoin address" box to be resized until it is symmetrical- Once the "send as zero-fee transaction" box is ticked, the recommended and custom tickers/boxes get disabled (grayed out)The recommended and custom boxes still have value because they will apply if the transaction size is greater than 1 KB as those values will be used as the transaction fee. Transactions > 1 kb cannot be free, under the default rules.- Remove hard to understand sentences (too much information going on at once) such as these:Will the casual user click the "Choose..." button to get more control over the transaction fee? Most of these fields apply to a coin like bitcoin, which has a congested network. We could simply hide all these extra fields unless they have non-default values based on transaction history. The smart fee system looks at the recent block history and the fees for the transactions and comes up with estimates for confirmation times and fees. In our testnet and in the goldcoin mainnet, there aren't enough transactions to trigger this to show recommended fees other than 0.001.
- "Smart fee not initialized yet, This usually takes a few blocks...)"
- Remove the part from the "confirmation time target" with only the time, no block amount, the block amount doesnt matter to the casual user.These sentences create confusion and isn't important to the casual user, if you feel like having more information about that option replace the sentence with a simple "?" box where the user receives a popup where they can read more about that following option.If the user wants a simple experience, then the "Hide" button works well. Granted that most of the options in the transaction fees section are redundant and not necessary for a coin with a low transaction volume.
- Jeroen
Keep in mind that changes (additions or deletions) to any words, sentences or phrases will require translation into the other languages and we don't have any translators or a system to get those translations.
My preference is to change as little as possible, partially because my expertise with C++ is the protocol and not the user interface (QT).
Send as zero-fee transaction, if possible (read the tooltip)
I think it should be like in the latest release but make the text;Send as zero-fee transaction, if possible (read the tooltip)
And add a tooltip explaining this 1Kb transaction size.
Agree on hiding all the extra sliders and text by default if the recommended fee for a fast transaction confirmation is the same as the Required Fee.
Ok.
Just got "error: couldn't connect to server: timeout reached (code 0)
(make sure server is running and you are connected to the correct RPC port)
Definitely still relevant. Eliminating ambiguity with every 'end user' is the goal but ultimately sacrifices usability to some degree.
After looking at the code, I think there is a way to the second option, which the user enters 0.00000000 for the fee.
Currently, that will still result in the minimum fee being paid.