This topic has been moved to Service Announcements.

https://bitcointalk.org/index.php?topic=766011.0

Not hardware

This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=765148.0

Dupe thread. Goto:
https://bitcointalk.org/index.php?topic=763314.0

[http://solo.ckpool.orgNo frills, no fuss 2% fee anonymous solo bitcoin mining for everyone]

http://solo.ckpool.org

No frills, no fuss 2% fee anonymous solo bitcoin mining for everyone

No registration required, no payment schemes no pool op wallets

Note that mining here means contributing to segwit activation since this is the logical choice for the bitcoin network moving forward. Bitcoin unlimited is a disruptive hostile fork that does not have bitcoin's best interest at heart and they do not have the expertise to maintain the network's health safely and securely.

Configuration:
Just point your miner to: stratum+tcp://solo.ckpool.org:3333 or port 443
Asicminer tube/prisma owners need to point to a special proxy at solo.ckpool.org:3335
If you use an incompatible rental service that refuses to work on port 3333 try port 4334

Set your username to your btcaddress with any or even no worker extension, and any password.
eg: cgminer -o stratum+tcp://solo.ckpool.org:3333 -u 1PKN98VN2z5gwSGZvGKS2bj8aADZBkyhkZ.0 -p x
If you enter an invalid address you will be rejected

Pick the server nearest you!
Server locations:
US Mid: mine to solo.ckpool.org:3333
Germany: mine to de.ckpool.org:3333
Mainland China ONLY:
    cnsolo.ckpool.org:3333
    cnsolo.ckpool.org:4334 For High Diff/Low bandwidth mining only.

Blocks solved:
https://btc.com/stats/pool/Solo%20CK

Suitable for:
    Large mining farms
    Regular miners struggling to recoup costs who wish to take extra risk for greater reward potential for part or all of their hashrate
    The last backup for all miners who don't have a solo setup or wish to avoid the overheads of running one
    Miners with old/inefficient miners that will never earn any rewards through regular mining that wish to leave it mining as a lottery

Proxy support:
Miners with many devices wishing to consolidate their devices into a single connection to solo ckpool are recommended to use the complementary ckpool code as ckproxy stratum proxy (for linux).
Ckpool code is available here: https://bitbucket.org/ckolivas/ckpool

Statistics:
Simple total pool statistics can be found at http://solo.ckpool.org/pool/
Solo.ckpool.org currently only displays minimal per user and per worker information based on btcaddress.
To access this, enter your BTC address at the end of: http://solo.ckpool.org/users/
or your workername at the end of: http://solo.ckpool.org/workers/

Advantages over regular solo mining:
Mining at solo.ckpool.org avoids the overheads of running a full bitcoin node that requires both great storage and bandwidth for optimal performance.
Solo.ckpool.org is extensively connected to high speed low latency bitcoin nodes for rapid block change notification and propagation.
Unlike regular pools, ckpool never mines transaction-free blocks due to its ultra-scaleable code which has miners on both new blocks and transactions concurrently.

How it works:
ckpool automatically takes your bitcoin address and gives you a unique stratum connection mining to your own address.
If you find a block, 98% of the block reward + transaction fees get generated directly at your bitcoin address!
There is no need to worry about passwords, logins, withdrawals, authentication or pool wallet hacks.
You remain anonymous apart from your btc address.
All you need to confirm you are mining to your own address is to examine the coinbase and template sent to you over stratum.
Note that if you do not find a block, you get no reward at all with solo mining.
2% goes to 1PKN98VN2z5gwSGZvGKS2bj8aADZBkyhkZ to operate the pool and contribute to further ckpool code development.


Pool code and pool operated and created by Con Kolivas, creator of cgminer and ckpool.

This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=752831.0
There are enough BFL bashing threads. There is no need for this to be in a separate thread.

This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=756280.0

One self moderated thread promoting your products is already too much.

This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=744765.0
Referral links

This topic has been moved to Trashcan.

https://bitcointalk.org/index.php?topic=741045.0
Duplicate post

An ever-increasing problem is the blatant ignoring of free software licenses from countries with no real recourse of action against them. Specifically my concern, being the author of cgminer, is that it is free software licensed under the Gnu Public License version 3 and there are now more and more hardware manufacturers from China creating their own forks and distributing binary-only versions of cgminer outside of China without any source code being provided and any requests for source are ignored. (Note that this is NOT universal and there are some manufacturers from China who strictly abide by the guidelines.)

Given the forum has a policy regarding that "Trading of goods that are illegal in the seller's or buyer's country is forbidden", the Chinese manufacturers selling their hardware to clients throughout the world means they are effectively violating this policy. They are using the forum as their main announce/advertising outlet for other countries while abusing the reach of laws that don't affect them across their borders. While cgminer is affected in this way, there is no doubt that with the vast majority of bitcoin-related code being released under free software licenses, that this problem will increase over time.

I've posted this in the public meta section because I wish public discourse on this issue along with hopefully an official stance on this issue.

Ref: https://bitcointalk.org/index.php?topic=3629.0

Sometimes a post really is of interest to 2 (or more) completely unrelated subsections and there is a need to post in both, usually for announcement purposes. There really is no need for there to be two separate threads created in such circumstances if there was a way for there to be a linked version in two different sections, much like a hard link in unix filesystem terms.

Most questions from newcomers to the forum are repeat questions and whenever people are asked why they didn't search first they insist they did and did not find what they were looking for...

Insert discussion about possible improvements to search facility here:

For those of us who get a lot of forum notifications, and the mods that get reports need to have a simple way to start/stop all forum notifications temporarily for example for when we are away and do not wish to come home to hundreds of emails, and to reject all attempts to send private messages to let people know we're currently away and not accepting messages.

Discussion goes here 

I've tried to collate all the relevant stratum documentation in one place since it is scattered over the forum and the original documentation links are hard to find. I'll add whatever relevant extensions were developed in this thread. I will try to add them to this thread to avoid them being lost on the internet.

Original protocol announce thread:
https://bitcointalk.org/index.php?topic=108533.0

Official website for the protocol now:
http://stratumprotocol.org/

Stratum protocol extensions:
http://stratumprotocol.org/stratum-extensions

Please do not post about CPU, GPU or altcoin mining in these boards, instead use the sub forums located here instead.

Thank you.

I recently implemented GBT solo mining with cgminer and have confirmed its ability to generate blocks on both testnet and the main bitcoin network. However I encountered an issue when I was running it with a high hashrate on a local testnet with only 2 nodes where generation was very rapid. This was on bitcoind 0.8.6

Here is the debug log:

Code:

2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 AddToWallet 7e6b9062686f1899a1c7fac650a8f8814512ca3d46dd1ddc9e9a4754b234b0c9  new
2014-03-23 13:41:47 NotifyTransactionChanged 7e6b9062686f1899a1c7fac650a8f8814512ca3d46dd1ddc9e9a4754b234b0c9 status=0
2014-03-23 13:41:47 updateWallet 7e6b9062686f1899a1c7fac650a8f8814512ca3d46dd1ddc9e9a4754b234b0c9 0
2014-03-23 13:41:47 Committing 300 changed transactions to coin database...
2014-03-23 13:41:47 SetBestChain: new best=00000000c4bf4b3cc072bd1cb614869f38b0160d6dd06a91ded695b8c42d198e  height=56195  log2_work=52.435666  tx=93784  date=2014-03-23 13:41:48 p
rogress=1.000000
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47    inWallet=1 inModel=0 Index=95-95 showTransaction=1 derivedStatus=0
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=getblockcount
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 received getdata for: block 00000000c4bf4b3cc072bd1cb614869f38b0160d6dd06a91ded695b8c42d198e
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:47 ThreadRPCServer method=submitblock
2014-03-23 13:41:47 ProcessBlock: ACCEPTED
2014-03-23 13:41:48 ThreadRPCServer method=submitblock
2014-03-23 13:41:48 ProcessBlock: ACCEPTED
2014-03-23 13:41:48 ThreadRPCServer method=submitblock
2014-03-23 13:41:48 ProcessBlock: ACCEPTED
2014-03-23 13:41:48 ThreadRPCServer method=submitblock
2014-03-23 13:41:48 ProcessBlock: ACCEPTED
2014-03-23 13:41:48 ThreadRPCServer method=submitblock
2014-03-23 13:41:48 ProcessBlock: ACCEPTED
2014-03-23 13:41:48 ThreadRPCServer method=submitblock
2014-03-23 13:41:48 ProcessBlock: ACCEPTED
2014-03-23 13:41:48 ThreadRPCServer method=submitblock
2014-03-23 13:41:48 ProcessBlock: ACCEPTED

So the first block was accepted and appeared fine in the wallet but after that, bitcoind appeared to go stupid and accepted all the blocks submitted but never really seemed to do anything with them. Is this simply a symptom of running only 2 nodes or is there a potential real problem with generating multiple valid block solves and submitting them? Note they were all almost certainly solves for the same height block and not subsequent blocks.

[with 230 of 400 posts deleted]

Self moderated topics have the warning at the top:

This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.

One thing that may be of interest to someone reading such a topic would be to know some objective marker of how many posts were deleted that they can then make their own judgements about how reliable the content in it is. A simple change like this would be helpful:

This is a self-moderated topic with 230 of 400 posts deleted. If you do not want to be moderated by the person who started this topic, create a new topic.

With the constant barrage of altcoin mining discussions continually moved from the mining subsections, half of the topics visible in the recent posts are simply "Moved" topics. Can the moved topics be automatically demoted instead? I know there is some logic in them still being visible but it's just a nuisance when so much is moved.

https://bitcointalk.org/index.php?topic=28402.msg3538435#msg3538435

[TL:DR]

Most pools are moving to a variable difficulty or minimum variable difficulty setting to avoid the bandwidth flood that occurs with ASIC hardware, but a lot offer the option of setting a fixed target or the minimum yourself per worker. There is an endless stream of questions on almost every separate pool's thread on what difficulty they should set if setting it manually. Note that you CANNOT EARN MORE by tweaking the difficulty.

So to make it easier, I'm going to give you a mathematically suggested strategy - this is all my opinion based on the maths though since there is no one true answer.

Setting the difficulty low for your hardware risks causing floods of bandwidth problems for both the miner and the pool operators.
Setting the difficulty high for your hardware causes no potential for communication problems, but the higher the difficulty, the more variance your payouts will see (i.e. your pay will fluctuate more) but it will average out to the same pay over time.
No bitcoin mining hardware device currently in existence uses the diff internally - they all mine at diff 1 and the mining software filters out results below what your pool has set it to so it makes no difference what hardware you use as to what diff you mine at.

i.e. only hashrate matters.

So we definitely don't want the difficulty too low, but what should we use as the cut off for how high to set the diff?

Organofcorti did a wonderful analysis of this last year:
http://organofcorti.blogspot.com/2012/10/71-variable-pool-difficulty.html

There is no magic endpoint to choose since the graph of share return rate versus variance is a curve - however - above a certain share return rate, 1% variance is small enough that it is much less than the pool's own luck's variance, and unless you were mining PPS there's a good chance you wouldn't be able to distinguish the difference on any one day. You also need a much bigger jump in share return rate before you can get below that 1% variance.

So my suggestion is to aim for a share return rate no higher than the highest difficulty that keeps you at 1% variance if you are setting a "minimum difficulty" or perhaps the value that keeps you under 1.2% for a fixed difficulty. This can be worked out easily if you know your hashrate without even testing it.

So our target is a diff that returns 20-25 shares per minute.
Every 71.6MH/s returns one share per minute - therefore every GH/s returns about 14 shares per minute.

A share return rate of 20 needs a diff of 1 per 1.432GH/s if setting a fixed difficulty.
A share return rate of 25 needs a diff of 1 per 1.79GH/s if setting a minimum difficulty.

Most pools are allowing you to set a fixed diff, so let's keep this final recommendation as simple as possible, and aim for 20 shares per minute. That's a diff of 1 per 1.432GH/s. The accuracy of this maths is not that important since the final endpoint is arbitrary anyway so we can knock off a few significant digits off our final recommendation.

TL:DR
Set your diff to your worker's hashrate in GH / 1.4

http://gcaptain.com/mol-comfort-incident-photos/