jzhoulon
|
|
October 18, 2014, 07:25:06 AM |
|
guys v2 pool last 6-9 hours not work ??
same here last payout at midnight and last block with submitted share is 24000. Dev, any word? Should be fixed now. thanks for timely update
|
|
|
|
jzhoulon
|
|
October 18, 2014, 07:31:47 AM |
|
uray, your miner reads plots by 4kB chunks. Maybe better enlarge that size? Even clustersizes are upto 64kB.
And what about single read-thread per path?
yeah its possible, but currently i am busy working on wallet hy uray, which features are you implementing on wallet??? if it is possible to know!!! i am integrating java miner & plotter into wallet, and convert it to desktop app This looks amazing. Keep up the good work yes its great, can't wait to test it Uray, its Wulfcastle here, designer of the current Wallet UI & Burst Logo/OP Graphics. I dumped all of my BURST around a month back, mainly due to the supply being diluted with around ~3.7 Million BURST per day, but now it has reached the point where BURST has enough infrastructure, largely thanks to you, to make a big push to compete with the big names in the crypto-space. Everything is virtually set in place, all BURST needs now is an easier to use client and miner (which is what your desktop application will accomplish) and the right marketing and promotion, which I can provide. If you have a test version ready of your desktop app for Windows that I can try out, I will come back to BURST and begin designing and promoting BURST once again. uray, this offer still stands. If you can send me a test version of this client, that I can assess, I will come back to BURST and begin designing/promoting once again. Hey Wulf, nice to see you back. How simple of a client do you need, specifically? We need a PR team with a promoter or two that can help drive this project to it's potential and beyond. Definitely want you on board..... pwallet is very nice, and @Wulf , is your logo for burst still in progress? have been waiting for several month.still expect that you can release your logo for burst in commnunity, burst coin still have not a logo.
|
|
|
|
soronto
Member
Offline
Activity: 66
Merit: 10
|
|
October 18, 2014, 09:01:09 AM |
|
uray, your miner reads plots by 4kB chunks. Maybe better enlarge that size? Even clustersizes are upto 64kB.
And what about single read-thread per path?
yeah its possible, but currently i am busy working on wallet hy uray, which features are you implementing on wallet??? if it is possible to know!!! i am integrating java miner & plotter into wallet, and convert it to desktop app This is one is amazing. One of the best wallet I have ever seen.
|
|
|
|
|
ReDPoiSoN
|
|
October 18, 2014, 10:53:20 AM |
|
We have to update before block ...!? Thanks
|
|
|
|
Prototyp
|
|
October 18, 2014, 11:00:50 AM |
|
Good Work!
|
|
|
|
mercyground
Newbie
Offline
Activity: 20
Merit: 0
|
|
October 18, 2014, 11:22:02 AM |
|
Hello!
I need some tips on how should I deal with a plot file...
ls -alt /mnt3/plots/XXXXXXXXXXXXXXXXXXXX_9498624_5578752_4096 -rw-r--r-- 1 root root 1459742441472 Sep 20 22:19 /mnt3/plots/XXXXXXXXXXXXXXXXXXXX_9498624_5578752_4096
The miner process always outputs error reading from file e.printStackTrace() reveals to be an java.io.EOFException at java.io.RandomAccessFile.readFully(RandomAccessFile.java:421) at java.io.RandomAccessFile.readFully(RandomAccessFile.java:399) at pocminer_pool.ScoopReader.readFile(ScoopReader.java:35) ................
while f.readFully(chunk); chunk (rs.staggeramt * MiningPlot.SCOOP_SIZE) is 262144 bytes = 256 kb
This plot's size in bytes is 1459742441472, thus 1459742441472 / 262144 = 5568475.5 (does not divide fully), so the java.io.EOFException is totally legit. 5578752 plots * 256kb = 1462436364288, but my plot actually is 2693922816 bytes short. Maybe the plotter process got killed, or got bad I/O,and never got to write the full file.
I'm thinking about deleting the last 131072 bytes from the file. Do I also need to rename the plot to XXXXXXXXXXXXXXXXXXXX_9498624_5568475_4096 (changed the nr of nounces to reflect new size) ?
|
|
|
|
burstcoin (OP)
|
|
October 18, 2014, 11:36:43 AM |
|
Hello!
I need some tips on how should I deal with a plot file...
ls -alt /mnt3/plots/XXXXXXXXXXXXXXXXXXXX_9498624_5578752_4096 -rw-r--r-- 1 root root 1459742441472 Sep 20 22:19 /mnt3/plots/XXXXXXXXXXXXXXXXXXXX_9498624_5578752_4096
The miner process always outputs error reading from file e.printStackTrace() reveals to be an java.io.EOFException at java.io.RandomAccessFile.readFully(RandomAccessFile.java:421) at java.io.RandomAccessFile.readFully(RandomAccessFile.java:399) at pocminer_pool.ScoopReader.readFile(ScoopReader.java:35) ................
while f.readFully(chunk); chunk (rs.staggeramt * MiningPlot.SCOOP_SIZE) is 262144 bytes = 256 kb
This plot's size in bytes is 1459742441472, thus 1459742441472 / 262144 = 5568475.5 (does not divide fully), so the java.io.EOFException is totally legit. 5578752 plots * 256kb = 1462436364288, but my plot actually is 2693922816 bytes short. Maybe the plotter process got killed, or got bad I/O,and never got to write the full file.
I'm thinking about deleting the last 131072 bytes from the file. Do I also need to rename the plot to XXXXXXXXXXXXXXXXXXXX_9498624_5568475_4096 (changed the nr of nounces to reflect new size) ?
Yes, it reads based on what it sees in the filename, and your numbers look correct. If you don't care about the tiny waste in space, you can also just do the rename without deleting the extra bytes, or you can just leave it alone since it will still use all the chunks it can read.
|
BURST-QHCJ-9HB5-PTGC-5Q8J9
|
|
|
mercyground
Newbie
Offline
Activity: 20
Merit: 0
|
|
October 18, 2014, 11:44:15 AM |
|
Hello!
I need some tips on how should I deal with a plot file...
ls -alt /mnt3/plots/XXXXXXXXXXXXXXXXXXXX_9498624_5578752_4096 -rw-r--r-- 1 root root 1459742441472 Sep 20 22:19 /mnt3/plots/XXXXXXXXXXXXXXXXXXXX_9498624_5578752_4096
The miner process always outputs error reading from file e.printStackTrace() reveals to be an java.io.EOFException at java.io.RandomAccessFile.readFully(RandomAccessFile.java:421) at java.io.RandomAccessFile.readFully(RandomAccessFile.java:399) at pocminer_pool.ScoopReader.readFile(ScoopReader.java:35) ................
while f.readFully(chunk); chunk (rs.staggeramt * MiningPlot.SCOOP_SIZE) is 262144 bytes = 256 kb
This plot's size in bytes is 1459742441472, thus 1459742441472 / 262144 = 5568475.5 (does not divide fully), so the java.io.EOFException is totally legit. 5578752 plots * 256kb = 1462436364288, but my plot actually is 2693922816 bytes short. Maybe the plotter process got killed, or got bad I/O,and never got to write the full file.
I'm thinking about deleting the last 131072 bytes from the file. Do I also need to rename the plot to XXXXXXXXXXXXXXXXXXXX_9498624_5568475_4096 (changed the nr of nounces to reflect new size) ?
Yes, it reads based on what it sees in the filename, and your numbers look correct. If you don't care about the tiny waste in space, you can also just do the rename without deleting the extra bytes, or you can just leave it alone since it will still use all the chunks it can read. Thank you so much. I know now what to do in the future with incomplete plot files! Great work, dev!
|
|
|
|
timk225
|
|
October 18, 2014, 11:56:52 AM |
|
You people STILL waiting fore a miracle on this crapcoin? LAWL. I've moved on. My 10931 coins are still for sale at 800 satoshis each.
|
|
|
|
yuk
|
|
October 18, 2014, 12:13:14 PM |
|
You people STILL waiting fore a miracle on this crapcoin? LAWL. I've moved on. My 10931 coins are still for sale at 800 satoshis each.
're still waiting for the miracle that someone will buy your coins at 800 sat?
|
|
|
|
go6ooo1212
Legendary
Offline
Activity: 1512
Merit: 1000
quarkchain.io
|
|
October 18, 2014, 12:21:22 PM |
|
You people STILL waiting fore a miracle on this crapcoin? LAWL. I've moved on. My 10931 coins are still for sale at 800 satoshis each.
're still waiting for the miracle that someone will buy your coins at 800 sat? I'm diging more than 12000 burst daily with almost none power cost.. So I suggest you buy some ASSET with your 10931 Bursts instead of hating the coin...
|
|
|
|
Pilotseye
|
|
October 18, 2014, 12:25:37 PM |
|
You people STILL waiting fore a miracle on this crapcoin? LAWL. I've moved on. My 10931 coins are still for sale at 800 satoshis each.
We are waiting for the miracle that you actually really move on and not just talk about it since weeks
|
|
|
|
fivebells
|
|
October 18, 2014, 01:33:51 PM |
|
You people STILL waiting fore a miracle on this crapcoin? LAWL. I've moved on. My 10931 coins are still for sale at 800 satoshis each.
There's still 10000 bursts for you, if you can talk the price down to 50s by next week.
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
October 18, 2014, 01:48:46 PM |
|
From the "shoddily made flow chart", this algorithm looks like essentially a more complex and simpler (in different ways) version of scrypt, just with very high memory requirements. It is probably just as weak to ASICs, though I can't say for sure without more information. Do actual specifications exist for the algorithm? Also, is anyone interested in doing a BFGMiner port I can merge?
|
|
|
|
SpeedDemon13
|
|
October 18, 2014, 03:05:08 PM |
|
From the "shoddily made flow chart", this algorithm looks like essentially a more complex and simpler (in different ways) version of scrypt, just with very high memory requirements. It is probably just as weak to ASICs, though I can't say for sure without more information. Do actual specifications exist for the algorithm? Also, is anyone interested in doing a BFGMiner port I can merge?
This algo mines via hdd capacity. Only way an asic would be useful is during the plotting process, but that's not a mining process.
|
CRYPTSY exchange: https://www.cryptsy.com/users/register?refid=9017 BURST= BURST-TE3W-CFGH-7343-6VM6R BTC=1CNsqGUR9YJNrhydQZnUPbaDv6h4uaYCHv ETH=0x144bc9fe471d3c71d8e09d58060d78661b1d4f32 SHF=0x13a0a2cb0d55eca975cf2d97015f7d580ce52d85 EXP=0xd71921dca837e415a58ca0d6dd2223cc84e0ea2f SC=6bdf9d12a983fed6723abad91a39be4f95d227f9bdb0490de3b8e5d45357f63d564638b1bd71 CLAMS=xGVTdM9EJpNBCYAjHFVxuZGcqvoL22nP6f SOIL=0x8b5c989bc931c0769a50ecaf9ffe490c67cb5911
|
|
|
jumbo987
Newbie
Offline
Activity: 27
Merit: 0
|
|
October 18, 2014, 03:58:06 PM |
|
Can we get a mac wallet?? I'd like to get in on this and try the HDD mining, but I gotta have the OSX applications!
Just use linux version and run from terminal. I tired it on mac and it s working
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
October 18, 2014, 05:29:54 PM |
|
From the "shoddily made flow chart", this algorithm looks like essentially a more complex and simpler (in different ways) version of scrypt, just with very high memory requirements. It is probably just as weak to ASICs, though I can't say for sure without more information. Do actual specifications exist for the algorithm? Also, is anyone interested in doing a BFGMiner port I can merge?
This algo mines via hdd capacity. Only way an asic would be useful is during the plotting process, but that's not a mining process. It doesn't have to be a HD, it could just as well be (a lot of) RAM. This is essentially the same way scrypt works, except scrypt altcoins aren't using as much capacity.
|
|
|
|
SpeedDemon13
|
|
October 18, 2014, 06:02:33 PM |
|
From the "shoddily made flow chart", this algorithm looks like essentially a more complex and simpler (in different ways) version of scrypt, just with very high memory requirements. It is probably just as weak to ASICs, though I can't say for sure without more information. Do actual specifications exist for the algorithm? Also, is anyone interested in doing a BFGMiner port I can merge?
This algo mines via hdd capacity. Only way an asic would be useful is during the plotting process, but that's not a mining process. It doesn't have to be a HD, it could just as well be (a lot of) RAM. This is essentially the same way scrypt works, except scrypt altcoins aren't using as much capacity. It's possible to do RAMDisk, but that's not a very cost effective way of mining. You would need a bunch of TB worth of RAM to mining with as oppose to cheaply doing it with HDDs. You try it out and give the results if it is worth it.
|
CRYPTSY exchange: https://www.cryptsy.com/users/register?refid=9017 BURST= BURST-TE3W-CFGH-7343-6VM6R BTC=1CNsqGUR9YJNrhydQZnUPbaDv6h4uaYCHv ETH=0x144bc9fe471d3c71d8e09d58060d78661b1d4f32 SHF=0x13a0a2cb0d55eca975cf2d97015f7d580ce52d85 EXP=0xd71921dca837e415a58ca0d6dd2223cc84e0ea2f SC=6bdf9d12a983fed6723abad91a39be4f95d227f9bdb0490de3b8e5d45357f63d564638b1bd71 CLAMS=xGVTdM9EJpNBCYAjHFVxuZGcqvoL22nP6f SOIL=0x8b5c989bc931c0769a50ecaf9ffe490c67cb5911
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
October 18, 2014, 06:06:56 PM |
|
From the "shoddily made flow chart", this algorithm looks like essentially a more complex and simpler (in different ways) version of scrypt, just with very high memory requirements. It is probably just as weak to ASICs, though I can't say for sure without more information. Do actual specifications exist for the algorithm? Also, is anyone interested in doing a BFGMiner port I can merge?
This algo mines via hdd capacity. Only way an asic would be useful is during the plotting process, but that's not a mining process. It doesn't have to be a HD, it could just as well be (a lot of) RAM. This is essentially the same way scrypt works, except scrypt altcoins aren't using as much capacity. It's possible to do RAMDisk, but that's not a very cost effective way of mining. You would need a bunch of TB worth of RAM to mining with as oppose to cheaply doing it with HDDs. You try it out and give the results if it is worth it. Yes, you can do the same thing with scrypt...
|
|
|
|
|