I have seen no mention of this yet so I thought I would bring it up: https://www.ivymclemore.com/blogThe Bitcoin inventor Satoshi Nakamoto is actually James Caan (James Bilal Khalid Caan): I mined 980,000 Bitcoins using a remote computer and my laptop in 2009. As Hal Finney explained this in his 2013 Bitcointalk post quite accurately, “those were the days when difficulty was 1, and you could find blocks with a CPU, not even a GPU.”
The real news is that the 980,000 BTC is lost forever. I am a bit surprised that news of the loss of 4.67% of the total supply of BTC has had no impact on the price. Now, it could be worse, Phil. I know your IRS dealings are a PITA but at least you did not lose $19 billion like James did. |
|
|
|
|
Just when you think it won't get much worse, it does. This is the first time I have seen WTM with negative earnings for all coins (given my GPU mix). I have only been mining for about a year and a half, however. If I didn't heat my house with my rigs, they would be off right now.
|
|
|
|
|
Does anybody know what is driving down most of the market today by ~15%? I have been looking for news but have not yet found anything. One would think coindesk would have something but ...
|
|
|
|
I don't think this will be extremely helpful because it doesn't answer your question directly, but maybe it will provide some clues. I am running the 3.0-stable release which is Ubuntu 18.04.1 and CUDA V9.2.148 by default. The interesting part is that it also has CUDA 8 installed. So, I started looking into how it supports CUDA 8 by toggling back to it. I started by grepping for cuda in the mining directory. There were two hits of interest - 0miner and screenrc-miner-cuda-8. So in screenrc-miner-cuda-8, we have these env var changes to toggle back to 8: ## set cuda-8.0 env for older miners
setenv PATH /usr/local/cuda-8.0:$PATH
setenv LD_LIBRARY_PATH /usr/local/cuda-8.0/lib64:$LD_LIBRARY_PATH
And this screenrc is called by 0miner with this code: # List of cuda-8.0 miners
CUDA_8_MINERS="ANXccminer ASccminer KXccminer MSFTccminer NAccminer SILENTminer SPccminer SUPRminer VERTMINER"
LAUNCH="screen -c ${NVOC}/screenrc-miner -dmSL miner"
for miner in $CUDA_8_MINERS
do
if [[ ${!xminer} =~ $miner ]]; then
LAUNCH="screen -c ${NVOC}/screenrc-miner-cuda-8 -dmSL miner"
fi
done
So, if the coin you chose has a miner that requires CUDA 8, then it toggles $LAUNCH to use a different screenrc which in turn handles the necessary env var tweaks. Hope this helps. |
|
|
|
|
Oh, geez, fk2. I wouldn't know where to start with that. While I understand nvOC better than most, if I found myself in that situation, I would start over with a fresh image. I say that because the most time consuming part for me is in getting the OC settings right for each GPU and algo/miner. I presume you have those saved off in 1bash copies (I use a spreadsheet and 1bash copies) so it may be faster to just start over.
Just my 2 cents.
|
|
|
|
tyvm stubo, that worked like a charme for X16R. @Luke: unfortunately that didn't work out for bminer and ethminer. this is what it should look like: ethminer -SP 2 -U -S daggerhashimoto.LOCATION.nicehash.com:3353 -O YOUR_BTC_ADDRESS_HERE.WORKER-NAME:x according to https://www.nicehash.com/help/ethereum-miningI used this here: screen -c /home/m1/NVOC/mining/screenrc-miner -dmSL miner /home/m1/NVOC/mining/miners/ETHMINER/recommended/ethminer -SP 2 -U -S daggerhashimoto.eu.nicehash.com:3353 -O 39qjQtznWGrsQAcbgQCa4VjQyMonzDNSUK.Icemine01:x
but there is no ethminer in the given path.../recommended, therefore no screen given named miner I did some more digging in 1bash and 0miner and, to me, there seems to be a big gap for support of NiceHack in 0miner. The only relevant code I could find is this: ## NICEHASH
if [[ ${COIN:0:4} == NICE ]]
then
NICE_NEOSCRYPT_ADDRESS=$NICE_ADDRESS
NICE_LYRA2REV2_ADDRESS=$NICE_ADDRESS
NICE_X11GOST_ADDRESS=$NICE_ADDRESS
NICE_SKUNKHASH_ADDRESS=$NICE_ADDRESS
NICE_CRYPTONIGHT_ADDRESS=$NICE_ADDRESS
NICE_EQUIHASH_ADDRESS=$NICE_ADDRESS
NICE_ETHASH_ADDRESS=$NICE_ADDRESS
but nothing references those variables after they are set there. I think there needs to be some more logic in that section that sets the x% variables specifically for NH. |
|
|
|
Here is what works for NICE_X16R screen -c /home/m1/NVOC/mining/screenrc-miner -dmSL miner /home/m1/NVOC/mining/miners/ZENEMYminer/recommended/ccminer -a x16r -o stratum+tcp://x16r.eu.nicehash.com:3366 -u 39qjQtznWGrsQAcbgQCa4VjQyMonzDNSUK
Please default in next versions I think what is missing is this line in 1bash, in the NICE_X16R section: NICE_X16R_ADDRESS=$NICE_ADDRESS
NICE_ADDRESS is supposed to be set by the user on line 439 of 1bash: NICE_ADDRESS="NICEHASH_BTC_ADDRESS" # Your internal Nicehash BTC addrees to use with nicehash
... but I could be wrong. Reading the new way that addresses, ports, pools, etc. is now specified is a bit confusing: That is from 0miner. |
|
|
|
|
I am on nvOC 19-3.0-stable and noticed that BCI was top of the heap (earnings on WTM) a few hours ago so I decided to dig into it and look into how/if it is supported in this version. The first thing that I noticed is that BCI is listed in 1bash but it appears as an equihash algo coin. Obviously, that is old as BCI is now progPow so it requires a different miner.
Before I re-invent the wheel and modify my 1bash and 0 miner to handle progPow and BCI, is this available in a new branch that I am unaware of?
Thanks in advance.
|
|
|
|
That line about "pro settings" just refers to more complex policies for OC levels, like algo specific with gpu offset. They are quite complex to understand at a first glance but will be clear what they do once someone realize he needs such useful policies.
That type of OC is just what I want as I have 2 hosts with GPUs that are the same model (e.g., 1080 Ti) but from different vendors so they require different power and clocks. Ideally, I would like to be able to OC per model/vendor and again for algo. Currently, I do this with different 1bash files named 1bash_$coin. I suppose that is the least painful way to do it. My point was that I see this one mention of it in 1bash but no support for it in 3main. Which branch has it? |
|
|
|
Hey Devs: I found a bug in the nvOC script. I noted that it was not reporting the max power limit for GPUs correctly so I dug in. On line 196 of the 3.0-stable release, you have this: POWERMAX=$(echo "$PWRLIMIT/1" | bc)
but it should be POWERMAX=$(echo "$POWERMAX/1" | bc)
Also, where can I find more info on this (from 1bash of 3.0-stable): # - Pro Settings are not for the faint-hearted. Dont use if you dont know what they are.
I scoured 1bash and 3main for this release and don't see anything else about it. Perhaps it is in a different release branch? Thanks. |
|
|
|
@stubo every time you open a gnome-terminal to its default profile nvOC runs again from scratch, it is like this from fullzero nvOC autostart method design. If you just need a shell open guake or lauch gnome-terminale with another profile. There is an alternative to gnome-terminal autostart based on systemd. Dig further in the code, the initial setup install may suffer some rough edges but in the end works like a charm, and the restart/stop commands are much more reliable.
The option in firstboot to use a different path works, but you simply can't use your user profile home as the root of a git repo. You must specify an empty folder where the m1 user has write access. Regarding the target branch name, it has to be an existing branch of the git repo. Go to github, whatever you see as git branch name is a valid string to put there, release (latest stable release, currently fed up from 3.0-stable, will upgrade to 4.0 whenever released), 19-2.1 (old dev branch), 3.0-stable (the current stable branch), 3.1-dev (the current dev branch) or any other feature branch of whatever is not merged yet, including your own branches if you have push rights to the git repo.
If you would like to write some good doc about firstboot.json options would be just awesome.
Thanks for the tips. I don't have much time to devote to this unlike this time last year. I will say again what a great job you guys have done here and I realize how hard it is to be perfect, but you have to try, right? So, I have it up and running on my test rig now and I just noticed that "nvoc start" now works in REMOTE mode. This is AWESOME as it gives one the ability to do lots of things like change OC, COIN, etc. on the fly without a reboot. Start never did work in 19-2.0 when in REMOTE but it worked fine for LOCAL. I am very happy to see you guys got it working fully. |
|
|
|
"release" branch is always same as latest stable branch which is now "3.0-stable" You can set nvoc_branch to "3.0-stable" for 3.0 in firstboot.json or "release" which will get updated when new stable branch get released. Try to run a firstboot with its defaults and see how it goes Edit: These problems occur when you leave the team for too long  Yep, it has been a while. I used the defaults and that worked fine. But when I try to use firstboot to set nvoc_path to just /home/m1, it goes craptastic (same errors as post above) and I am left with a base Ubuntu install. Why give people the option to set it if it doesn't work? The recompile miners and expand disk options did work fine, however. The other bug that I wanted to point out is that if while running REMOTE, on the console, every time I open a terminal it tries to re-run nvOC. I didn't dig into the details but whatever launches that should check to see if it is already running. All that I wanted to do was open a terminal to troubleshoot miner startup issues right there on the console without having to ssh in from another machine. Enough with the bad, what is really cool is the reorganization of 1bash and the total rewrite/streamlining of 0miner. It took me a few minutes to figure out what is going on with 0miner as it is such a deviation from the very repetitive old version. Kudos on that. The downside is that adding a new miner that doesn't fit the mold of an existing algo is quite cumbersome. However, I don't figure most people would ever need to do that. But overall, great job to the team. I am pleased to see how much progress you guys have made. |
|
|
|
Hey Pap and All:
It has been a long time and it would appear that lots of work has been done.
What is the best way to get started from nothing and get up to the latest version? My rigs are all on 19.2.0 and I just want to start over and hopefully get the latest Ubuntu and Cuda toolkit. I want to play around with mining RVN and the latest Z-enemy miner seems to require at least Cuda 9 and I am stuck at Cuda 8 with my older versions.
Thanks in advance.
Hi mate Long time... Have a look at nvOC GitHub readme if you want to make a new image or check This Post to just get the latest nvOC Both 16.04 and 18.04 images download and set latest release point at first boot. There is some issue on ubuntu 18.04 with tempcontrol which fans wont update and we gets multiple instances of it on some rigs after running for a while and we cant figure out why it happens. My test rig with 3 cards shows no problem, but rigs with 6+ cards does. If you have time to install 18.04 and see if you can pinpoint the problem would be a big help I followed the directions as per the README.md, specifically "For insiders: Pre-built images targeting beta/pre-release branches". I couldn't find good documentation for the firstboot.json mods. I had a question about the release naming and could not find it anywhere. So I ended up with a bunch of failures: Thu Oct 25 03:07:35 EDT 2018 - nvOC FirstBoot start
+ Looking for the small fat partition
/media/m1/12D3-A869 is not a mountpoint
++ mounting fat partition
+ Parsing firstboot.json
++ selected branch: '3.0'
++ nvOC will install to: '/home/m1'
+ Wait for internet connection to continue nvOC setup
Connection to google.com 443 port [tcp/https] succeeded!
+ Cloning '3.0' nvOC branch into /home/m1
++ Checking if selected branch actually exists...
+++ Selected branch not found, falling back to 'release'
++ /home/m1 already exists, cleaning up
rm: cannot remove '/home/m1/.config/enchant': Permission denied
rm: cannot remove '/home/m1/firstboot/tmplogs': Device or resource busy
fatal: destination path '/home/m1' already exists and is not an empty directory.
+ Updating miners submodule
++ No cache found in /home/m1/.miners-cache
fatal: not a git repository (or any of the parent directories): .git
+ Checking free space
++ Available free space in root partition: 100773288 KB
+ Installing miners (recompile: true)
/home/m1/firstboot/firstboot.sh: line 118: pushd: /home/m1/miners: No such file or directory
bash: nvOC_miner_update.sh: No such file or directory
/home/m1/firstboot/firstboot.sh: line 129: popd: directory stack empty
+ Looking for your customized 1bash
dos2unix: converting file /home/m1/1bash to Unix format...
+ Setting 2unix as custom-command for gnome-terminal 'mining' profile
bash: /home/m1/firstboot/profile-manager.sh: No such file or directory
+ Determining if firstboot can be disabled
++ FAILURE: keeping firstboot as default gnome-terminal profile
++ This script will run again on the next reboot.
++ Check your fat partition contents or internet connectivity.
+ Saving firstboot_90ccfd.log to small fat partition and /home/m1/firstboot
Thu Oct 25 03:07:36 EDT 2018 - Done.
cp: cannot stat '/home/m1/firstboot/tmplogs/firstboot.log': No such file or directory
cp: cannot stat '/home/m1/firstboot/tmplogs/firstboot.log': No such file or directory
I used value "3.0" and home of "/home/m1" but that was a guess as it could have been lots and lots of things - "nvOC-19.3.0", nvoc-19_3.0" and on and on. It also looks like the script defaulted to "release" which was promising but still failed. What is the secret release to use for this field? Also, is it problem to use home "/home/m1"? I don't like having superfluous extra subdirectories if not absolutely necessary. |
|
|
|
|
Hey Pap and All:
It has been a long time and it would appear that lots of work has been done.
What is the best way to get started from nothing and get up to the latest version? My rigs are all on 19.2.0 and I just want to start over and hopefully get the latest Ubuntu and Cuda toolkit. I want to play around with mining RVN and the latest Z-enemy miner seems to require at least Cuda 9 and I am stuck at Cuda 8 with my older versions.
Thanks in advance.
|
|
|
|
Every bloody day several shitcoins are coming out. Not a single good one in the last few months. It's pathetic actually, it's not even worth trying to instamine because the value on the trash exchanges they might get listed at isn't even worth your electricity.
Haven is an interesting idea. Here is the whitepaper: https://havven.io/uploads/havven_whitepaper.pdfThe first few pages make my head hurt because they are using brain cells that have not been exercised in nearly 30 years. |
|
|
|
Algo switch working on MPH?
Yes, I am using the equihash autoswitch and auto-exchange to BTC w/o issues for the past 2 weeks. |
|
|
|
MPH switching performed poorly yesterday too. I think we may be seeing the effect of all our asics.
yesterday
2018-07-12 (UTC) 0.00354236 (btc)
vs 3 previous days
2018-07-11 (UTC) 0.00439799 (btc)
2018-07-10 (UTC) 0.00454665
2018-07-09 (UTC) 0.00440286
I had similar results on MPH as well, with yesterday being a down day. What did you get on 7/8/2018? That day was even worse than yesterday for me so I suspect down days are normal. |
|
|
|
Wow that thing looks beastly! Makes me realize how much of a small time miner I am. In dec/Jan 2017/2018. I had 30 1080tis and 20 1070tis I was around 30000 sols and making around 300 a day. It was nice while it lasted. How much would the same amount of hash make today? How far down are we? Per whattomine.com, 30k sols would earn about $50 on an equihash coin today. |
|
|
|
Has anyone tried ZEN on MPH? with the Z9...
Yes. I have mined ZEN and ZEC with my Z9 mini on MPH. I am currently using the Equihash Autoswitch URL which switches between them (as well as ZCL) based upon profit. |
|
|
|
|
Show Posts
