[ANN] [ASIC-RESISTANT] UltraCoin (UTC) - Ultrafast 6 second transactions!!

[HackaB321]

What's normal hashrate of a r9 290 in scrypt-jane?

[Halofire]

What's normal hashrate of a r9 290 in scrypt-jane?

170-180kh at current nfactor

[dbappa]

I must be doing something wrong as I only get 140 Kh/S. Someone with the better hash rate care to post their config please? Mine is below:

-o stratum+tcp://utc.idcray.com:10001 -u -p --scrypt-jane --sj-nfmin 4 --sj-nfmax 30 --sj-time 1388361600 -w 256 -I 13 -g 1 --lookup-gap 2 --thread-concurrency 45000 -Q 0 -E 10 --gpu-engine 1025 --gpu-memclock 1250 --temp-target 76 --auto-fan --gpu-fan 40-80 --temp-cutoff 90 --temp-overheat 85 --no-submit-stale --scan-time 1 --queue 0

[xwebnetwork]

I must be doing something wrong as I only get 140 Kh/S. Someone with the better hash rate care to post their config please? Mine is below:

-o stratum+tcp://utc.idcray.com:10001 -u -p --scrypt-jane --sj-nfmin 4 --sj-nfmax 30 --sj-time 1388361600 -w 256 -I 13 -g 1 --lookup-gap 2 --thread-concurrency 45000 -Q 0 -E 10 --gpu-engine 1025 --gpu-memclock 1250 --temp-target 76 --auto-fan --gpu-fan 40-80 --temp-cutoff 90 --temp-overheat 85 --no-submit-stale --scan-time 1 --queue 0

What card are you using?

[Thirtybird]

I must be doing something wrong as I only get 140 Kh/S. Someone with the better hash rate care to post their config please? Mine is below:

-o stratum+tcp://utc.idcray.com:10001 -u -p --scrypt-jane --sj-nfmin 4 --sj-nfmax 30 --sj-time 1388361600 -w 256 -I 13 -g 1 --lookup-gap 2 --thread-concurrency 45000 -Q 0 -E 10 --gpu-engine 1025 --gpu-memclock 1250 --temp-target 76 --auto-fan --gpu-fan 40-80 --temp-cutoff 90 --temp-overheat 85 --no-submit-stale --scan-time 1 --queue 0

You can crank up the intensity all the way without problem with the amount of memory you have allocated.  You're going to be shader-bound.  I don't like using -I for shader-bound coins, but you'd have to switch mining software to get access to -X (xIntensity)

[TheStuhlman]

Another big pool is having problems in the last two days, so I delayed Nitro2 till they resolve their issues, releasing Nitro2 now will be counterproductive, we do not want to take miners from other pools, we are trying to spread the hash, not pile up more miners on Nitro.
If you guys do not mind I'd rather wait 2 more days for this after which we will release Nitro2 that should give everyone proper time to prepare.
Also some other pools are doing quite well marketing right now, so do not want to jump in quick on their growth. Our idea behind Nitro2 is to
move some of our miners from pool A to pool B and not get a rush from new miners. The latest increase in miners on Nitro is not caused by us.
It should be resolved soon.

Nitro: We gotta wait 2 more days when it's been 2-3 weeks at least since I've known you've had the highest hashrate problem? N-factor is only 2 weeks away. Every day counts. Please reconsider.  By delaying Nitro 2, you are still enabling the problem. Even is you did 'steal' miners from other pools, you would be allowing the other pools to be mining correctly, no orphans. miners and pools both make more UTC by opening Nitro 2. So it's a win win.


I wanted to remain loyal to my pool and spread the hashes, but I've lost 50% of my minings in pointless hashing due to orphans at leet. 4-5 UTC in last 5 hours, calculated at least 600 UTC loss for a 30 day period, but since there are variables, I'd say I've lost at least 450 coins for the last 3 weeks. I receive 25 UTC/day. so that's approximately half. Am I a loyal fool? At .00022, I am just breaking even for electric.

Laterbreh: I appreciate all you've done and loyalty is a big deal for me, which is why I haven't left leet until now. I can't afford to lose anymore, I've hit the turning point. Maybe another coin, another time, or if nitro really reduces it's hashrate. Mining at your pool is 2x more expensive. Nfactor coming up, i need to make back some UTC before it's too late. The thing I don't understand is why lesser pools than leet have 0 orphans from what I've read in the past in this thread.


An idea for the future: since miners and pool owners can't come to an agreement or figure this problem out, in my opinion, this is a problem that can only be solved by encoding something in the coin. We need a "pool-resistant" or "pool difficulty specific" coin for lack of better term, where a coin can sense which nodes have more hashing power than others and raises difficulty for those nodes with higher hashes.  

Halo I explained that high orphan rate is not related to high hash rate at another pool. There is way too many factors to this. You can ask the other pool owners if they are having the same problem. All the pools get orphans, and it occurs more when the block time is faster. But your persistence to blame the orphan problem on us is beyond me. Why would our hashrate cause orphans at one pool and not another?

I know exactly why you are having issues and I posted it earlier on this thread. If you had bothered to read my advice you would not have been in this situation. I said it once and say it again once your pool reach 270MH it will fail, did you believe me then NO, and when the ddos hit our pool the quick jump on your pool put you over that fail line. So the fail came sooner than later. And it was compounded by the ddos on us to a point of no return.
Every time our pool went down for a little bit, the problem at your pool was growing. If you remember the first day of UTC launch, IDcray had the same issue because they had high hashrate from day one, and they closed signups quickly because they did not know how to deal with it. Now you want more, when the next Nfactor kicks in the fail line will be at 180MH after which a small pool will fail to operate. Our creation of Nitro 2 is mainly to satisfy the community, and bring some peace to this thread. It's a shame we have to keep going back to this. Read my earlier posts on this thread about these issues.

As for your suggestion for pool resistant hash diff etc.., please read it again. If your suggestion is practical I would be mining UTC blocks on a CPU at 0.000001 difficulty and you will be mining it at your pool at 5 or 6 diff.

[HackaB321]

I have a R9 290 + HD 5770. With previous n-factor I had no issue, now I'm getting a lot of hw errors. My config is:

setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_USE_SYNC_OBJECTS 1
ultracoinminer -o stratum+tcp://ultra.leetpools.com:3333 -u HackaB321.worker1 -p a --scrypt-jane --sj-nfmin 4 --sj-nfmax 30 --sj-time 1388361600 -w 256 --thread-concurrency 24550,8000 -I 15,12 --lookup-gap 2 --auto-fan --temp-target 85 --temp-overheat 91 --gpu-engine 1000,880 --gpu-memclock 1500,1250 --gpu-powertune 20 --expiry 10 --scan-time 1 --queue 0

Any suggest? Thanks

[reflexmk]

What card are you using?

Any update on the page you suggested yesterday? Or maybe a sapphire 280 dual-x recommended bios? Thanks

[xwebnetwork]

What card are you using?

Any update on the page you suggested yesterday? Or maybe a sapphire 280 dual-x recommended bios? Thanks

No, not yet. But in the interim, here are some of my modified BIOS files and their respective models/voltages. I've also included a copy of ATIWinFlash. Furthermore, I have an ASUS bios and a Gigabyte BIOS, just not on me at the moment. Will upload later.

https://www.dropbox.com/sh/g894zll2mrsd7gy/hEnCekUOmZ

NOTE: I highly recommend you back up your stock BIOS. I only have the Toxic stock in their now but will upload the rest soon as I get home.

The numbers correspond to the voltage and I have only included one's that have been running stable for me with the following config:

Code:

--scrypt-jane --sj-nfmin 4 --sj-nfmax 30 --sj-time 1388361600 -I 12 --gpu-engine 1000 --gpu-memclock 1250 -w 256 -g 2 --auto-fan --temp-target 75 --temp-overheat 80 --temp-cutoff 85 --thread-concurrency 16384

A good, full Windows guide can be found here if you want to experiment with additional voltages: http://releasethecrypto.com/undervolting.html

[batty634]

nitro delaying the second pool to help other pools, what a load of nonsense. I've been patient up until now, however the bs meter is off the chart.

Split the pool already, you are damaging the coin

[laterbreh]

Another big pool is having problems in the last two days, so I delayed Nitro2 till they resolve their issues, releasing Nitro2 now will be counterproductive, we do not want to take miners from other pools, we are trying to spread the hash, not pile up more miners on Nitro.
If you guys do not mind I'd rather wait 2 more days for this after which we will release Nitro2 that should give everyone proper time to prepare.
Also some other pools are doing quite well marketing right now, so do not want to jump in quick on their growth. Our idea behind Nitro2 is to
move some of our miners from pool A to pool B and not get a rush from new miners. The latest increase in miners on Nitro is not caused by us.
It should be resolved soon.

Nitro: We gotta wait 2 more days when it's been 2-3 weeks at least since I've known you've had the highest hashrate problem? N-factor is only 2 weeks away. Every day counts. Please reconsider.  By delaying Nitro 2, you are still enabling the problem. Even if you did 'steal' miners from other pools, you would be allowing the other pools to be mining correctly, no orphans. miners and pools both make more UTC by opening Nitro 2. So it's a win win.


I wanted to remain loyal to my pool and spread the hashes, but I've lost 50% of my minings in pointless hashing due to orphans at leet. 4-5 UTC in last 5 hours, calculated at least 600 UTC loss for a 30 day period, but since there are variables, I'd say I've lost at least 450 coins for the last 3 weeks. I receive 25 UTC/day. so that's approximately half. Am I a loyal fool? At .00022, I am just breaking even for electric.

Laterbreh: I appreciate all you've done and loyalty is a big deal for me, which is why I haven't left leet until now. I can't afford to lose anymore, I've hit the turning point. Maybe another coin, another time, or if nitro really reduces it's hashrate. Mining at your pool is 2x more expensive. Nfactor coming up, i need to make back some UTC before it's too late. The thing I don't understand is why lesser pools than leet have 0 orphans from what I've read in the past in this thread.


An idea for the future: since miners and pool owners can't come to an agreement or figure this problem out, in my opinion, this is a problem that can only be solved by encoding something in the coin. We need a "pool-resistant" or "pool difficulty specific" coin for lack of better term, where a coin can sense which nodes have more hashing power than others and raises difficulty for those nodes with higher hashes.  

I completely understand, and I don't blame anyone. I am currently running some multi-variant tests and patches to try and resolve the orphan issue. You mine where its profitable for you, but right now we can understand the attrition from miners, and we dont blame anyone. Our pool is not going anywhere and we will figure something out to get all the pools running smooth so everyone can enjoy a pleasant mining experience no matter what pool they are on.

PS Hey devs can we get an update on the src? Multithread support... etc... there is a list of basic stuff that needs to get put into this wallet thats really causing extra work on the pool owners ends to make shit work.

[ozzy1926]

nitro delaying the second pool to help other pools, what a load of nonsense. I've been patient up until now, however the bs meter is off the chart.

Split the pool already, you are damaging the coin

yea, i dont think they care about other pools

[SxC]

nitro delaying the second pool to help other pools, what a load of nonsense. I've been patient up until now, however the bs meter is off the chart.

Split the pool already, you are damaging the coin

yea, i dont think they care about other pools

ppl need to quit the hate towards Nitro pool owners the guys are doing the best they can im sure

[xwebnetwork]

@laterbreh

I'd really like to know this as well. +1

Seems like the wallet could use a plethora of small but imperative updates and if Ziggy is not available, somebody else needs to be brought on board to address the issues.

[dcgirl]

@laterbreh

I'd really like to know this as well. +1

Seems like the wallet could use a plethora of small but imperative updates and if Ziggy is not available, somebody else needs to be brought on board to address the issues.

Let me echo this - Bumface, can you address whether Ziggy can help with this, or if we should be recruiting someone? Thx.

[Creds]

Hi,

I'm trying to make ultracoind on Windows 7 64, receive the following error:

[C:\ultracoin\src]mingw32-make -f makefile.mingw
g++ -mthreads -O2 -msse2 -w -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -g -DWIN32 -D_WINDOWS -DBOOST_THR
EAD_USE_LIB -DBOOST_SPIRIT_THREADSAFE -DUSE_IPV6=0 -I"C:\deps\boost" -I"C:\deps\db\build_unix" -I"C:\deps\ssl\include\openss
l" -I"C:\deps\ssl\include" -Wl,--dynamicbase -Wl,--nxcompat, -static -o Ultracoind.exe -L"C:\deps\boost\stage\lib" -L"C:\dep
s\db\build_unix" -L"C:\deps\ssl" obj/alert.o obj/version.o obj/checkpoints.o obj/netbase.o obj/addrman.o obj/crypter.o obj/k
ey.o obj/db.o obj/init.o obj/irc.o obj/keystore.o obj/main.o obj/net.o obj/protocol.o obj/bitcoinrpc.o obj/rpcdump.o obj/rpc
net.o obj/rpcmining.o obj/rpcwallet.o obj/rpcblockchain.o obj/rpcrawtransaction.o obj/script.o obj/sync.o obj/util.o obj/wal
let.o obj/walletdb.o obj/noui.o obj/kernel.o obj/pbkdf2.o obj/scrypt-x86.o obj/scrypt-x86_64.o obj/scrypt_mine.o -l boost_sy
stem-mgw46-mt-d-1_53 -l boost_filesystem-mgw46-mt-d-1_53 -l boost_program_options-mgw46-mt-d-1_53 -l boost_thread-mgw46-mt-d
-1_53 -l boost_chrono-mgw46-mt-d-1_53 -l db_cxx -l ssl -l crypto -l kernel32 -l user32 -l gdi32 -l comdlg32 -l winspool -l w
inmm -l shell32 -l comctl32 -l ole32 -l oleaut32 -l uuid -l rpcrt4 -l advapi32 -l ws2_32 -l mswsock -l shlwapi
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe: cannot find : Invalid argument
collect2: ld returned 1 exit status
mingw32-make: *** [Ultracoind.exe] Error 1

Some help, please!!!

[noobyonekenobi]

nitro delaying the second pool to help other pools, what a load of nonsense. I've been patient up until now, however the bs meter is off the chart.

Split the pool already, you are damaging the coin

yea, i dont think they care about other pools

looks like you Two are mining from leet?  You should try differnet pool like utc.pool.pm and you will not complain. 

(Im not paid by pool.pm)

[Halofire]

Halo I explained that high orphan rate is not related to high hash rate at another pool. There is way too many factors to this. You can ask the other pool owners if they are having the same problem. All the pools get orphans, and it occurs more when the block time is faster. But your persistence to blame the orphan problem on us is beyond me. Why would our hashrate cause orphans at one pool and not another?

I know exactly why you are having issues and I posted it earlier on this thread. If you had bothered to read my advice you would not have been in this situation. I said it once and say it again once your pool reach 270MH it will fail, did you believe me then NO, and when the ddos hit our pool the quick jump on your pool put you over that fail line. So the fail came sooner than later. And it was compounded by the ddos on us to a point of no return.
Every time our pool went down for a little bit, the problem at your pool was growing. If you remember the first day of UTC launch, IDcray had the same issue because they had high hashrate from day one, and they closed signups quickly because they did not know how to deal with it. Now you want more, when the next Nfactor kicks in the fail line will be at 180MH after which a small pool will fail to operate. Our creation of Nitro 2 is mainly to satisfy the community, and bring some peace to this thread. It's a shame we have to keep going back to this. Read my earlier posts on this thread about these issues.

As for your suggestion for pool resistant hash diff etc.., please read it again. If your suggestion is practical I would be mining UTC blocks on a CPU at 0.000001 difficulty and you will be mining it at your pool at 5 or 6 diff.

i was not aware of your explanation earlier in the thread. I must have skipped it somehow or I misinterpreted it. Makes sense about the first half of what you said. My apologies. Thanks for explaining again. Laterbreh just confirmed what you said that it was with our pool, and answered why other pools had 0% orphans.


As for my suggestion, yes, you kinda got the idea, but you exaggerate what I mean with your numbers and you are too ''early'' on the exponential curve (E curve), as i explain. you're saying my idea lets it be easier for cpu's but not for gpu's just like the effect n-factor has, getting paid the same for more work. I agree, but thats not my starting point. My idea is not as detrimental to the little guys as to encourage several medium sized pools instead of one huge pool. what is the maximum hashrate for a cpu, ~170? max hashrate for gpu is 1000 give or take. scale the diff like an E curve. yes gpus would have higher diff, thats the point and is already seen in nfactor.

But you dont have to do what I just explained. Gives the feel of my idea. The E curve could be set so that every farm or pool hashrate up to, lets say 100MH or if we want a percent of net hashrate - we'll say 30%, is still in the same diff group as one card with 50KH. Anything past the the 100MH or 30% would start to skyrocket.  This results in the E  curve effects taking off and targeting huge pools to encourage hashes spreading out. diff would be based on: hashrate divided by total net hashrate times 100. 1 pool owner could have several larger-medium-sized pools.  Nitro 1, 2, 3 and so on. All my numbers would have to be tweaked, i'm only using examples. Could use percentages of net hashrate instead of a written in stone interger to allow flexibility and growth. Thoughts?

 Coinwarz would have fun with this one.... lol

[Halofire]

laterbreh, glad to hear you're working on it. will be glad to come back once you sort things out. PM me when ya do.

[laterbreh]

nitro delaying the second pool to help other pools, what a load of nonsense. I've been patient up until now, however the bs meter is off the chart.

Split the pool already, you are damaging the coin

yea, i dont think they care about other pools

looks like you Two are mining from leet?  You should try differnet pool like utc.pool.pm and you will not complain. 

(Im not paid by pool.pm)

If what were working on works and resolves the orphan issue, I will bet UTC that pool.pm will have the same issue we have unless they apply the measures we are taking. I will gladly share the information once I verify it is working.