Bitcoin Forum
May 24, 2024, 07:44:23 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 [69] 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 »
1361  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient POC Mining | New version 1.1.2 on: September 26, 2014, 08:40:10 AM
Native C++ Miner Update 1.1 R4

binaries and source available here : https://github.com/uraymeiviar/burst-miner/releases
for osx, linux64 and win64

  • capable to read large stagger plot, with manual limit option on memory usage
  • Fix thread race condition, which reported to less nonce read
  • add option of buffer size (MB) in mining.conf to limit memory usage

and also, github automatically give the project website : http://uraymeiviar.github.io/burst-miner/

ty uray for the release R4....

i'm using windows..

can you explain how to tune "maxBufferSizeMB" param?
now i have this behaviour:

java miner: HIGH ram usage, but low CPU usage
Uray's miner: HIGH cpu usage, but low RAM usage..

it is correct for you???

or i set up some wrong param?

using higher maxBufferSizeMB should make miner read plot faster but use more memory usage,
using lower maxBufferSizeMB make miner use less memory, in exchange to slower read

you can tune this value to make the miner finish reading plot within 2-3 minutes
1362  Alternate cryptocurrencies / Mining (Altcoins) / Re: Native Burst miner [OSX] [Win] [Linux] on: September 25, 2014, 10:50:18 PM
New Native C++ Miner Update 1.1 R4

binaries and source available here : https://github.com/uraymeiviar/burst-miner/releases
for osx, linux64 and win64

  • capable to read large stagger plot, with manual limit option on memory usage
  • Fix thread race condition, which reported to less nonce read
  • add option of buffer size (MB) in mining.conf to limit memory usage
1363  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient POC Mining | New version 1.1.2 on: September 25, 2014, 10:15:32 PM
Native C++ Miner Update 1.1 R4

binaries and source available here : https://github.com/uraymeiviar/burst-miner/releases
for osx, linux64 and win64

  • capable to read large stagger plot, with manual limit option on memory usage
  • Fix thread race condition, which reported to less nonce read
  • add option of buffer size (MB) in mining.conf to limit memory usage

and also, github automatically give the project website : http://uraymeiviar.github.io/burst-miner/
1364  Alternate cryptocurrencies / Pools (Altcoins) / Re: [POOL] burst-pool.cryptoport.io [ No-Deadline Limit ] [ Instant Payout ] on: September 25, 2014, 10:13:57 PM
New Native C++ Miner Update 1.1 R4

binaries and source available here : https://github.com/uraymeiviar/burst-miner/releases
for osx, linux64 and win64

  • capable to read large stagger plot, with manual limit option on memory usage
  • Fix thread race condition, which reported to less nonce read
  • add option of buffer size (MB) in mining.conf to limit memory usage
1365  Alternate cryptocurrencies / Pools (Altcoins) / Re: [POOL] burst-pool.cryptoport.io [ No-Deadline Limit ] [ Instant Payout ] on: September 24, 2014, 04:26:19 AM
uray, your new miner is nice, but uses a huge amount of RAM. Normal? Is there any way to limit usage?



use small stagger size 4096 or 8192
1366  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient POC Mining | New version 1.1.2 on: September 23, 2014, 09:21:54 PM
anyone else on urays pool and constantly getting failed to submit nonce. wtf is going on here.

i'm asking for this too!!!

better official pool V2 or uray's poll??



Urays second pool http://burst-pool2.cryptoport.io/ has problems, but http://burst-pool.cryptoport.io/ works just fine for me.


http://burst-pool.cryptoport.io  works here just fine as well

I am mining there and have had 50 coins in 3 days. always says failed to submit nonce after first submit sucess. was working well untill few days ago when pool front showed we were on block 3000 ish. been fud ever since.

which miner are u using? if its not the latest from me, then most of the time it will failed to submit nonce, there are almost 200 miners there, you need to delay the nonce submission
1367  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient POC Mining | New version 1.1.2 on: September 22, 2014, 10:31:08 PM
ANNOUNCEMENT:

I have stopped mining this piece of shit crapcoin.  I hadn't had a payout for DAYS with 10.43 TB of disk space pimping away, I was tired of the piece of crap Java miner hogging 9 GB of ram for two instances of mining, I'm tired of the developers' half-assed miner and having to do half the programming work just to compile and run the damn thing.

My 4 3TB Seagate Barracuda hard drives are on ebay right now for a VERY fair $340 and free shipping in the USA.

Furthermore, I predict that this crapcoin will never see 500 satoshis again.  Anyone who tries to talk it up by saying things like "to da mooooooon", is a fool, an idiot, and a moron.

So screw this crapcoin and everything about it.

Basically whe you say screw everything about this coin you are telling us all to f*ck off...
Thats not very nice of you.


I have been mining and minting and whatnot more than 30 altcoins the last half year, and nowhere have i seen more competent developers and a more productive main developer but here. I am staying. I don't mind other ppl leaving cause that means my plots generate more coins. In the long run this one will be one of the main altcoins, in fact, it already is, only not so many have found out yet.

My 20TB will be shipped on the 24th and will be operational a few days after that. I would really love a price crash and some of the more childish people leave, cause that will leave more burst to be had by the ones who are in for the long haul. Looking back at how short a period of time this coin has been live, the innovation and the development (and the quality of software developed) is lots higher than what i see in the  professional software development world. I surely hope the dev team behind this coin like good beer, cause there might just one day happen to drop a large box of said liquind on their doorstep. (not now... down the line..)

BTW seagate barracuda disks (at least the 3TB version) are  extremely crappy by my experience. i've had two of these crash in short order, while all my other 3TB drives have been working flawlessly. I hope for seagate that they've gotten their shit together reg. their 4tb drives.

It's amazing to see how many ppl are actively contributing to the coin and the software. Cheers to every one of you.. it is very much appreciated.




+1 i've been mining hundreds of altcoins since a year or two, even i did mining bitcoin using CPU, when the price is still like 0.1$ / btc, and NO... i am not rich.. i loss all those easy earned bitcoin on satoshi dice!, the moral of the story is... its so easy to overlooked great innovation when the price is very very low, i don't ever thinking twice when i put 5 BTC bet on satoshidice a long time ago, cause its just 0.5$ !, now we see most people so easy dumping thousands of burst at the price of < 100 sats ...

why i am so eager to support development of this coin is because i am so bored with hundreds of copy-cat so called innovative coin, with their new PoW algorithm, annon feature, proof-of-stake, some use funky name, some even have VOIP feature put into their wallet (which make me laugh) in desperate to give innovation, even we have dedicated callendar for coin launch, and everyday there is new coin launch! what a crazy world

burst giving a fresh breath to crypto world, not only its greener to run than bitcoin, litecoin and other alts, burst also more asic resistance since it does not rely on computation, and also burst is free from Proof of stake flaw of rich getting richer, its better distributed since harddrive is easier to get and maintain than GPU or ASIC, and also its free from CPU-coins flaw that can be abused by bot-net or any infected PCs. day by day network capacity is increasing, we almost have 9 Peta Bytes now, that's great network infrastructure if we can utilize it better.

there are lot of potential, we still have a lot to do, we are talking too much about technical side of mining, and less commercial and social, we need to build better and bigger community for this coins

1368  Alternate cryptocurrencies / Pools (Altcoins) / Re: [POOL] burst-pool.cryptoport.io [ No-Deadline Limit ] [ Instant Payout ] on: September 22, 2014, 10:05:20 PM
Hi,
I just try new C++ miner And can ask you is this correct function?

Note: W7 64-bit, 950 GB generated with GPU

btw: I minig on burst pool v2 since Tuesday , but havent receive any payout



it seems your plots is fucked up, because pool's deadline is different than locally calculated deadline

Yae, I delete them and now genereating new with CPU.But when I run new C miner twice (on different PC but 1 address) I see in miners diffrent confirmed deadline and on pool also see different deadline , its correct(sometimes its same)? or its better use for one miner one address?. And please can you tell me what is means the last number(third, also someone have there dashes) in current round shares?

it should have same deadline on pool and on your miner, and on your miner's confirmed deadline message
current roundshare line is
Code:
<account-RS> <current round best deadline> <current-share-value> <burst-balance>
all roundshare line is
Code:
<account-RS> <all round-best-deadline> <all round share value> [<number of blocks since last payment>]
1369  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient POC Mining | New version 1.1.2 on: September 22, 2014, 09:25:41 PM
i dont get why everyone requires such much memory to plot.
i created a few 100 tb plots splitted in 2gb files with stagger 8191 and 8191 nonce which work great.
even the java plotter only used few hundred megabytes ram during plotting.
a 2 tb disk is read in less than 20 seconds during the mining and each miner instance runs with Xmx750m without crashes.
would i have any advantage if i would merge my disks and run eg. 10-30 tb plots instead of 120 miner instances reading many 2gb files in the cluster?


Only 100TB?
129*1.9tb for now as spare parts which i can mine with for 6 month or more as testcase.
also awaiting new hardware arrivals  Cool

Just try not to kill the price any more than it already has been killed, please kind sir.


On a negative note....


Today my 9 month old baby pulled one of my brand new 4TB drives to the floor while it was plotting in an external dock... The drive hit the ground without any protection at all, while spinning AND writing... I had my fiance try to plug it back in, but no luck with the drive showing up, hopefully it's something else and I can fix it when I get home, but I'm sorta leaning towards my drive being broken...


ironic, my first burst drive to break, is not from mining burst, but from my baby son.

so the moral of the story is burst and baby does not mix ?
1370  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient POC Mining | New version 1.1.2 on: September 22, 2014, 09:07:13 PM
i dont get why everyone requires such much memory to plot.
i created a few 100 tb plots splitted in 2gb files with stagger 8191 and 8191 nonce which work great.
even the java plotter only used few hundred megabytes ram during plotting.
a 2 tb disk is read in less than 20 seconds during the mining and each miner instance runs with Xmx750m without crashes.
would i have any advantage if i would merge my disks and run eg. 10-30 tb plots instead of 120 miner instances reading many 2gb files in the cluster?


why u need multiple miner instance? which miner are u using?

if you want to be safe, and use less memory while mining, keep stagger size low (<= 8192), merging plot or not does not have any difference, why only 2GB files? its too small are u using FAT32 ?

So, why my miner use 14Gb of memory for 8Tb plots with 4096 stagger ?
There is a prolem with my plots ?

i don't know exatcly, but i am using it fine for 15 TB, it use only 600MB for 8192 stagger
how do you create that plot? which plotter r u using?
1371  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient POC Mining | New version 1.1.2 on: September 22, 2014, 08:45:07 PM
i dont get why everyone requires such much memory to plot.
i created a few 100 tb plots splitted in 2gb files with stagger 8191 and 8191 nonce which work great.
even the java plotter only used few hundred megabytes ram during plotting.
a 2 tb disk is read in less than 20 seconds during the mining and each miner instance runs with Xmx750m without crashes.
would i have any advantage if i would merge my disks and run eg. 10-30 tb plots instead of 120 miner instances reading many 2gb files in the cluster?


why u need multiple miner instance? which miner are u using?

if you want to be safe, and use less memory while mining, keep stagger size low (<= 8192), merging plot or not does not have any difference, why only 2GB files? its too small are u using FAT32 ?
the origin is in the max staggersize of the original java plotter. i ran many nodes with custom scripts to plot the files automatically.
i thought if i had to move them from one node to another a 2gb chunk is quite handy for simple gigabit networks and also fits completely into the fs read and write buffers during the creation and distribution.
i realized the java miner on a average cpu can only handle about 8-10tb plots to stay below half of the blocktime cause of cpu load.
i havent analyzed this further cause i could avoid it by running a miner for each hdd. tests with bigger plotfiles resulted in much more memory usage so i was fine with up to 20 seconds parsing for 2tb and kept my inital setup like it was.
for me the question is if the compute power during the mining is required for the amount of nonce or for the disk seeks.
if i figure out a way to create the 20tb plots could this file also be parsed with one miner instance in time or is the cpu too slow and would skip most of it?


have you try using my miner, i want to know how the result compared to java miner, bigger plot file should not use more memory unless you set it to use larger stagger size, and, mining only did one shabal hash for each nonce to determine its deadline, is not computation intensive, most of time spent is on disk read/seek, and also mining only read 1/4096 of your data during each round
not yet cause i am fine with the java miner in my setup. on a average node i get a disk i/o of 500-600 mb/s when a new block arrives. this lasts for less than 15-20 seconds depending on the disks. its basically what the storage is capable of. can your miner mine with the default wallet or requires it the pool counterpart?


its pool only
1372  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient POC Mining | New version 1.1.2 on: September 22, 2014, 08:26:57 PM
i dont get why everyone requires such much memory to plot.
i created a few 100 tb plots splitted in 2gb files with stagger 8191 and 8191 nonce which work great.
even the java plotter only used few hundred megabytes ram during plotting.
a 2 tb disk is read in less than 20 seconds during the mining and each miner instance runs with Xmx750m without crashes.
would i have any advantage if i would merge my disks and run eg. 10-30 tb plots instead of 120 miner instances reading many 2gb files in the cluster?


why u need multiple miner instance? which miner are u using?

if you want to be safe, and use less memory while mining, keep stagger size low (<= 8192), merging plot or not does not have any difference, why only 2GB files? its too small are u using FAT32 ?
the origin is in the max staggersize of the original java plotter. i ran many nodes with custom scripts to plot the files automatically.
i thought if i had to move them from one node to another a 2gb chunk is quite handy for simple gigabit networks and also fits completely into the fs read and write buffers during the creation and distribution.
i realized the java miner on a average cpu can only handle about 8-10tb plots to stay below half of the blocktime cause of cpu load.
i havent analyzed this further cause i could avoid it by running a miner for each hdd. tests with bigger plotfiles resulted in much more memory usage so i was fine with up to 20 seconds parsing for 2tb and kept my inital setup like it was.
for me the question is if the compute power during the mining is required for the amount of nonce or for the disk seeks.
if i figure out a way to create the 20tb plots could this file also be parsed with one miner instance in time or is the cpu too slow and would skip most of it?


have you try using my miner, i want to know how the result compared to java miner, bigger plot file should not use more memory unless you set it to use larger stagger size, and, mining only did one shabal hash for each nonce to determine its deadline, is not computation intensive, most of time spent is on disk read/seek, and also mining only read 1/4096 of your data during each round
1373  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient POC Mining | New version 1.1.2 on: September 22, 2014, 07:59:58 PM
Math question: How can I calculate difficulty from baseTarget of block?

Does it still uses NXT's formula? https://wiki.nxtcrypto.org/wiki/Whitepaper:Nxt#Base_Target_Value

Was it changed when there is not Proof of Stake?

And most importantly: How can we estimate total network plot size from cumulative difficulty?

I'd like to graph it and offer to public as online tool.

Thanks in advance

baseTarget is the difficulty, to estimate network plot size i posted it here -> https://bitcointalk.org/index.php?topic=731923.msg8577852#msg8577852
1374  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient POC Mining | New version 1.1.2 on: September 22, 2014, 07:56:04 PM
i dont get why everyone requires such much memory to plot.
i created a few 100 tb plots splitted in 2gb files with stagger 8191 and 8191 nonce which work great.
even the java plotter only used few hundred megabytes ram during plotting.
a 2 tb disk is read in less than 20 seconds during the mining and each miner instance runs with Xmx750m without crashes.
would i have any advantage if i would merge my disks and run eg. 10-30 tb plots instead of 120 miner instances reading many 2gb files in the cluster?


why u need multiple miner instance? which miner are u using?

if you want to be safe, and use less memory while mining, keep stagger size low (<= 8192), merging plot or not does not have any difference, why only 2GB files? its too small are u using FAT32 ?
1375  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][BURST] Burst | Efficient POC Mining | New version 1.1.2 on: September 22, 2014, 04:42:57 PM

залить картинку на форум
WTF is this??? All plots are creating and optimizing with GPU and optimization.exe
anyone help me?
For all day i mine 2014-09-22 = 28.37191379 BURST
appr. 12Tb
my config:
 {
    "poolUrl" : "burst-eu.cryptomining.farm:8124",
    "submissionMaxDelay" : 30,
    "submissionMaxRetry" : 3,
    "socketTimeout" : 60,
    "plots" :
    [
       "G:\\plots",
       "E:\\plots",
"I:\\plots",
"H:\\plots",
"D:\\plots",
"F:\\plots",
"J:\\plots"

   ]
 }
Попробуй майнер моей редакции https://www.dropbox.com/s/85cequgcmlonc6z/miner-burst.zip?dl=0
строка запуска в твоем случае:
miner.exe pool burst-eu.cryptomining.farm 8124 G:\plots\ E:\plots\ I:\plots\ H:\plots\ D:\plots\ F:\plots\ J:\plots\


my miner is not work well with single stagger, 409600 is quite large, miner need to allocate continuous 52MB on RAM for each plot, multiplied that by 8 plots of yours, it need 400MB continous space, maybe it failed to do this, i can fix this but currently i dont have time yet

either you just use another miner (such as dcct's or java), or dont do any modification (such  as optimize) to your plot, just use stagger size of 4096 or 8192, you wont see any differences between optimized and un-optimized plot i think, because for example if you have 4 TB of plot, every 4 minutes miner only read 1 GB of those plot data and then its idle. doing disk seeks of 1GB every 4 minutes (on average) wont kill your drive

and doing the read as fast as you can and then submit it to pool as fast as you can will only do more harm than good for your earning, and useless since the miner will randomly delay the submission, without this delay there is good chance you got failed on nonce submission due to spike in pool's deadline processing, its because all pools based on my source dont have deadline limit, we accept all nonces and calculate that nonce into deadline, if everyone submitting nonce as fast as they can, then during every new block pool is flooded with nonce submission and most of them are crap nonce resulting in months or years of deadline
1376  Alternate cryptocurrencies / Mining (Altcoins) / Re: Claymore CryptoNote GPU Miner v7.0 - Windows and Linux on: September 22, 2014, 03:58:43 PM
Here is the full log, when I start the miner:
-----------
Code:
./miner -u 47NHu3QopHC7sBrqraNJwqD9xXAWErAsDiEr3QKQcX3rFyKfGa2CPJcXsG9qEiYHNDT2nf6BwZPFMW3rxtES1MPwN1bCMTm -p x -a 0

имммммммммммммммммммммммммммммммммммммммммммммммммммммммммммммммм╩
╨            Claymore CryptoNote GPU Miner  v7.0 Beta            ╨
хмммммммммммммммммммммммммммммммммммммммммммммммммммммммммммммммм╪

Cards available: 6
GPU #0: name: Tahiti, 2861 MB available, 28 units
GPU #1: name: Tahiti, 2869 MB available, 28 units
GPU #2: name: Tahiti, 2869 MB available, 28 units
GPU #3: name: Tahiti, 2869 MB available, 28 units
GPU #4: name: Tahiti, 2869 MB available, 28 units
GPU #5: name: Tahiti, 2869 MB available, 28 units
Total cards: 6

Catalyst 13.12 is REQUIRED for best performance and compatibility
At least 16 GB of Virtual Memory is required for multi-GPU systems
Make sure you defined GPU_MAX_ALLOC_PERCENT 100
Be careful with overclocking, use default clocks for first tests
Initializing...

POOL version
Internal error: Input OpenCL binary is not for the target!
Internal error: Input OpenCL binary is not for the target!
GPU 0: -a 1 mode selected
GPU 1: -a 1 mode selected
GPU 2: -a 1 mode selected
GPU 3: -a 1 mode selected
GPU 4: -a 1 mode selected
GPU 5: -a 1 mode selected
4 pools specified.
Stratum - connecting to 'mine.moneropool.org' <104.131.59.214> port 80
Stratum - connecting to 'mine.moneropool.org' <104.131.59.214> port 80
Stratum - Connected
Stratum - Connected
Pool Diff 10000
DevFee: Pool Diff 10000
GPU 0, GpuMiner k1a failed -48
GPU memory allocation failed. Try to set at least 16 GB of Virtual Memory: Computer Properties / Advanced System Settings / Performance / Advanced / Virtual Memory
GPU 1, GpuMiner k1a failed -48
GPU 3, GpuMiner k1a failed -48
GPU memory allocation failed. Try to set at least 16 GB of Virtual Memory: Computer Properties / Advanced System Settings / Performance / Advanced / Virtual Memory
GPU 5, GpuMiner k1a failed -48
GPU memory allocation failed. Try to set at least 16 GB of Virtual Memory: Computer Properties / Advanced System Settings / Performance / Advanced / Virtual Memory
GPU 2, GpuMiner k1a failed -48
GPU 4, GpuMiner k1a failed -48
GPU memory allocation failed. Try to set at least 16 GB of Virtual Memory: Computer Properties / Advanced System Settings / Performance / Advanced / Virtual Memory
GPU memory allocation failed. Try to set at least 16 GB of Virtual Memory: Computer Properties / Advanced System Settings / Performance / Advanced / Virtual Memory
GPU memory allocation failed. Try to set at least 16 GB of Virtual Memory: Computer Properties / Advanced System Settings / Performance / Advanced / Virtual Memory
09/18/11-15:23:53 - New job received from mine.moneropool.org:80
Speed: 0 h/s, TotalHashes: 0K, DevHashes: 0K Mining time: 00:00

The other thing that is bugging me, that in the both archives uploaded, have identical sizes, and both give me the warning "Catalyst 13.12 is REQUIRED for best performance and compatibility", although the files in the archives are different.

I use driver 14.4, set swap to 20GB, system memory is 2GB, 6 x 7950 cards. Operating system is Ubunty Server 14.04 LTS. Tried both versions, 13.12 and 14.6, both are giving me the error above.

+1 does not work on multi gpu, i have 16GB of RAM, 4GB of swap space, 2 GPU 280x, Linux 64

the symptom is it work if i use -di for single gpu, for multi it seems the miner keep allocating on wrong gpu index, i notice that if i run miner on single gpu, then run another instance to use second gpu only, miner says gpu free memory is down to 900MB, yes it should down from 3GB to 0.9GB for first gpu, but not for second gpu, so when the second instance want to allocate memory for second gpu, somehow it allocate to wrong gpu that is currently used hence the memory allocation failure
1377  Alternate cryptocurrencies / Pools (Altcoins) / Re: [POOL] burst-pool.cryptoport.io [ No-Deadline Limit ] [ Instant Payout ] on: September 21, 2014, 09:01:25 PM
with New Native C++ Miner Update 1.0 R3 for some plots I get following info, e.g.

plot read done. acc#_4000001_80000_80000 0 nonces

is this actually ok or are these plots fckd up?  Undecided

are you mining while generating plot? or generating is done?
a while ago, i did mining while generating it shows 0 nonce, and then i restart the miner, then it read the nonces, and then its no problem generating while mining.
and also check if the miner has read access to the file, maybe try with administrator priviledge first
1378  Alternate cryptocurrencies / Mining (Altcoins) / Re: The MOST ASIC Resistant Algo? on: September 21, 2014, 08:41:19 PM
burst

its asic resistant, bot-net resistant, gpu-resistant, cpu-resistant
what you need is free space on your storage, it does not even consume electricity more than hundreds watt or any cpu usage

On the instructions for BurstCoin it says that it can be mined with SHA-256 and SCRYPT miners... Any idea how that works? This is a really interesting concept.... Thanks for bringing this into the picture!

that is via multipool, so you mine SHA256 / scrypt coins, then those mined coins is sold into btc, and with that btc they buy Burst, this process is automatic via burst multipool
1379  Alternate cryptocurrencies / Mining (Altcoins) / Re: The MOST ASIC Resistant Algo? on: September 21, 2014, 03:18:30 PM
burst

its asic resistant, bot-net resistant, gpu-resistant, cpu-resistant
what you need is free space on your storage, it does not even consume electricity more than hundreds watt or any cpu usage
1380  Alternate cryptocurrencies / Mining (Altcoins) / Native Burst miner [OSX] [Win] [Linux] on: September 21, 2014, 12:31:00 PM
download binary here https://github.com/uraymeiviar/burst-miner/releases
source code is here https://github.com/uraymeiviar/burst-miner/
website is here http://uraymeiviar.github.io/burst-miner/

to configure, just edit mining.conf file in packaged bin, app will automatically look for this file when run, unless you specify costom .conf file

this is for burst pool v2 mining only
miner will use 2x staggerSize x 64 byte per plot file

  • it use C++ and native compiled, should be faster and less memory consumption compared to java miner
  • binary available for osx, win64 and linux64 (on linux most of the case you still need to recompile it, to do this clone source from github and issue "make" command
  • multithreaded miner, it will keep reading without pause when submiting share
  • added random delay when submitting nonce, to ensure you dont submitting nonce during peak submission on pool
  • it will auto retry if nonce submission is failed
  • multi account, multi-plots, just configure path to plot or directory inside mining.conf, it will autmatically search for valid plot file, dont worry if have another file inside plot directory, it wont read it
Pages: « 1 ... 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 [69] 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!