DCGirl that is awesome! I wish I could do things like this. How on earth have you done it? Did someone give you the template code? Very impressed
Thanks! I started with highstock (a plugin for highcharts), then built server code to get and summarize the data, and did some javascript to display it all. Still have a bunch of work to do, but this is a good base. 
Topic: [ANN] [ASIC-RESISTANT] UltraCoin (UTC) - Ultrafast 6 second transactions!! - page 333. (Read 946650 times)
March 19, 2014, 05:34:16 PM
March 19, 2014, 05:32:11 PM
DCGirl that is awesome! I wish I could do things like this. How on earth have you done it? Did someone give you the template code? Very impressed
March 19, 2014, 05:27:10 PM
As promised, here's a screenshot of the chart so far. I'm working on the orderbook, then history, then need to set it up to stream to the user (instead of the user pulling the data, it will be pushed). A few more days and it will be ready...
https://i.imgur.com/JtG2HZj.png
(Other changes - shorten decimal numbers, verify numbers are correct, more dynamic candlesticks, cryptsy and mintpal charts, compare three exchanges on a chart). I also have a lot of other things planned, but this will be release 1.
https://i.imgur.com/JtG2HZj.png
(Other changes - shorten decimal numbers, verify numbers are correct, more dynamic candlesticks, cryptsy and mintpal charts, compare three exchanges on a chart). I also have a lot of other things planned, but this will be release 1.
Awesome dcgirl +100
March 19, 2014, 05:18:13 PM
Dont forget to enter this weeks lottery www.ultracoinlottery.com
Draw is on Sunday 10am UTC
Any donations for the giveaway are welcome UjmaVKmXnY6pCo7FiyKpu9Ys4eggEize79
So far the jackpot is at 109 UTC
Draw is on Sunday 10am UTC
Any donations for the giveaway are welcome UjmaVKmXnY6pCo7FiyKpu9Ys4eggEize79
So far the jackpot is at 109 UTC
March 19, 2014, 05:16:14 PM
As promised, here's a screenshot of the chart so far. I'm working on the orderbook, then history, then need to set it up to stream to the user (instead of the user pulling the data, it will be pushed). A few more days and it will be ready...
(Other changes - shorten decimal numbers, verify numbers are correct, more dynamic candlesticks, cryptsy and mintpal charts, compare three exchanges on a chart). I also have a lot of other things planned, but this will be release 1.
(Other changes - shorten decimal numbers, verify numbers are correct, more dynamic candlesticks, cryptsy and mintpal charts, compare three exchanges on a chart). I also have a lot of other things planned, but this will be release 1.
March 19, 2014, 03:28:17 PM
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 poolsSplit the pool already, you are damaging the coin
(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.
March 19, 2014, 03:04:39 PM
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.
March 19, 2014, 03:01:59 PM
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
March 19, 2014, 02:44:50 PM
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 poolsSplit the pool already, you are damaging the coin
(Im not paid by pool.pm)
March 19, 2014, 02:35:04 PM
Hi,
I'm trying to make ultracoind on Windows 7 64, receive the following error:
Some help, please!!!
I'm trying to make ultracoind on Windows 7 64, receive the following error:
Quote
[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
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!!!
March 19, 2014, 02:32:50 PM
@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.
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.
March 19, 2014, 02:29:53 PM
@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.
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.
March 19, 2014, 02:26:15 PM
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 poolsSplit the pool already, you are damaging the coin
ppl need to quit the hate towards Nitro pool owners the guys are doing the best they can im sure
March 19, 2014, 02:04:51 PM
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 Split the pool already, you are damaging the coin
March 19, 2014, 02:04:11 PM
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.
March 19, 2014, 02:01:57 PM
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
Split the pool already, you are damaging the coin
March 19, 2014, 01:51:10 PM
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
March 19, 2014, 01:28:11 PM
Any update on the page you suggested yesterday? Or maybe a sapphire 280 dual-x recommended bios? Thanks
March 19, 2014, 01:13:48 PM
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
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
March 19, 2014, 01:01:38 PM
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.
Jump to: