[ANN] -NEW BURST OP- MINE ANY FREE SPACE-(HDD MINING)- ATs, AE, P2P MARKET+MORE! - page 112.

haitch

hero member

Activity: 539

Merit: 500

Quote from: callmejack on June 06, 2016, 06:35:31 PM

Quote from: drbobbo on June 06, 2016, 05:11:06 PM

I just noticed something, perhaps this is obvious and just me who don't understand how this works. I have plots on three machines (53 Tb + 10 Tb + 12 Tb). All plots are generated for the same account. Each machine runs a miner and all three miners are pointed at burst.ninja, but in the pool, I only see 53 Tb as ~capacity. Are the other two machines not mining, or is it just the pool which does not show the other two, but they are still being used?

Is there a better way to set this up? The computers (win 7) are physically in different locations so it is not trivial to share drives between them. I could mine with one account for each machine (just set up three burst accounts) but that means I have to replot 22 Tb of plots, which I hope I will not have to do ....

Thx

/

I am not sure if it is a good idea to submit deadlines from different miner instances for one account since higher deadlines may cause a penalty on pool side if one of the other miners already submitted a lower deadline.

anyone knows if there exists some sort of proxy for such setups?

if there exists none a total capacity above 50 tb should also be fine to mine solo with.

burst.ninja and pool.burst-team.us do not have that penalty.

As stated earlier is Blago's miner is used it will accurately report the size of one of the plots, on other miners the capacity is estimated.

H.

callmejack

sr. member

Activity: 256

Merit: 250

Quote from: drbobbo on June 06, 2016, 05:11:06 PM

I just noticed something, perhaps this is obvious and just me who don't understand how this works. I have plots on three machines (53 Tb + 10 Tb + 12 Tb). All plots are generated for the same account. Each machine runs a miner and all three miners are pointed at burst.ninja, but in the pool, I only see 53 Tb as ~capacity. Are the other two machines not mining, or is it just the pool which does not show the other two, but they are still being used?

Is there a better way to set this up? The computers (win 7) are physically in different locations so it is not trivial to share drives between them. I could mine with one account for each machine (just set up three burst accounts) but that means I have to replot 22 Tb of plots, which I hope I will not have to do ....

Thx

/

I am not sure if it is a good idea to submit deadlines from different miner instances for one account since higher deadlines may cause a penalty on pool side if one of the other miners already submitted a lower deadline.

anyone knows if there exists some sort of proxy for such setups?

if there exists none a total capacity above 50 tb should also be fine to mine solo with.

Vin

legendary

Activity: 1166

Merit: 1015

Quote from: drbobbo on June 06, 2016, 05:11:06 PM

I just noticed something, perhaps this is obvious and just me who don't understand how this works. I have plots on three machines (53 Tb + 10 Tb + 12 Tb). All plots are generated for the same account. Each machine runs a miner and all three miners are pointed at burst.ninja, but in the pool, I only see 53 Tb as ~capacity. Are the other two machines not mining, or is it just the pool which does not show the other two, but they are still being used?

Is there a better way to set this up? The computers (win 7) are physically in different locations so it is not trivial to share drives between them. I could mine with one account for each machine (just set up three burst accounts) but that means I have to replot 22 Tb of plots, which I hope I will not have to do ....

Thx

/

Here you can check if your plots overlap:

https://bchain.info/BURST/tools/overlap

daWallet

sr. member

Activity: 302

Merit: 250

Quote from: drbobbo on June 06, 2016, 05:11:06 PM

I just noticed something, perhaps this is obvious and just me who don't understand how this works. I have plots on three machines (53 Tb + 10 Tb + 12 Tb). All plots are generated for the same account. Each machine runs a miner and all three miners are pointed at burst.ninja, but in the pool, I only see 53 Tb as ~capacity. Are the other two machines not mining, or is it just the pool which does not show the other two, but they are still being used?

Is there a better way to set this up? The computers (win 7) are physically in different locations so it is not trivial to share drives between them. I could mine with one account for each machine (just set up three burst accounts) but that means I have to replot 22 Tb of plots, which I hope I will not have to do ....

Thx

/

Blago's miner sends the plot size to the pool. If you use the same account, probably the pool shows only the highest number.
If you use the Win Client for plotting, you should use different drive letters during plotting on each machine or another account. You should always check, that your plots don't overlap!

overdozedCEO

full member

Activity: 213

Merit: 100

Quote from: drbobbo on June 06, 2016, 05:11:06 PM

I just noticed something, perhaps this is obvious and just me who don't understand how this works. I have plots on three machines (53 Tb + 10 Tb + 12 Tb). All plots are generated for the same account. Each machine runs a miner and all three miners are pointed at burst.ninja, but in the pool, I only see 53 Tb as ~capacity. Are the other two machines not mining, or is it just the pool which does not show the other two, but they are still being used?

Is there a better way to set this up? The computers (win 7) are physically in different locations so it is not trivial to share drives between them. I could mine with one account for each machine (just set up three burst accounts) but that means I have to replot 22 Tb of plots, which I hope I will not have to do ....

Thx

/

Are you sure your plots are not overlapping?

drbobbo

newbie

Activity: 41

Merit: 0

I just noticed something, perhaps this is obvious and just me who don't understand how this works. I have plots on three machines (53 Tb + 10 Tb + 12 Tb). All plots are generated for the same account. Each machine runs a miner and all three miners are pointed at burst.ninja, but in the pool, I only see 53 Tb as ~capacity. Are the other two machines not mining, or is it just the pool which does not show the other two, but they are still being used?

Is there a better way to set this up? The computers (win 7) are physically in different locations so it is not trivial to share drives between them. I could mine with one account for each machine (just set up three burst accounts) but that means I have to replot 22 Tb of plots, which I hope I will not have to do ....

Thx

/

overdozedCEO

full member

Activity: 213

Merit: 100

I dropped my bounty-signature of some random coin to support the devs lil bit

Propagandalf

sr. member

Activity: 312

Merit: 250

Quote from: CIYAM on June 06, 2016, 10:19:25 AM

Quote from: Propagandalf on June 06, 2016, 03:23:49 AM

If I understand you correctly, will such a modification allow us to use existing files on a drive without "locking" them to the mining process? If so, will that not lead to a free-for-all for all huge data centres around the world who can then mine while still hosting server space? I believe dedicating free space to plotting/mining has so far been a deterrent to those players.

You haven't quite understood (but that is okay as I have not been that explicit as I'm trying to reach out to devs that might be able to "read between the lines").

The files that would be used would need to have been pre-announced (so that their hashes are actually known).

Exactly how that should work I haven't spent that much time considering so far (as it is mostly just an idea at this stage) but it would be fairly easy to limit the rate of expansion (making it more likely that smaller operators could expand to keep up with the total storage if they wanted to).

Over time the advantage would still be with those with more (and faster) storage but in order to get the files that the entire network might consider would first require the entire network to have accepted them (the "proof" is not the file content itself but the file content being modified from a starting nonce).

I am not a dev, but your explanation makes more sense to me now. Thanks.

overdozedCEO

full member

Activity: 213

Merit: 100

Quote from: tross on June 06, 2016, 11:51:42 AM

Yahoo new road map and on my birthday too! Kinda like a birthday present lol

Nice man! Its going to be a good birthday for sure Grin

tross

member

Activity: 112

Merit: 10

Yahoo new road map and on my birthday too! Kinda like a birthday present lol

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: Propagandalf on June 06, 2016, 03:23:49 AM

If I understand you correctly, will such a modification allow us to use existing files on a drive without "locking" them to the mining process? If so, will that not lead to a free-for-all for all huge data centres around the world who can then mine while still hosting server space? I believe dedicating free space to plotting/mining has so far been a deterrent to those players.

You haven't quite understood (but that is okay as I have not been that explicit as I'm trying to reach out to devs that might be able to "read between the lines").

The files that would be used would need to have been pre-announced (so that their hashes are actually known).

Exactly how that should work I haven't spent that much time considering so far (as it is mostly just an idea at this stage) but it would be fairly easy to limit the rate of expansion (making it more likely that smaller operators could expand to keep up with the total storage if they wanted to).

Over time the advantage would still be with those with more (and faster) storage but in order to get the files that the entire network might consider would first require the entire network to have accepted them (the "proof" is not the file content itself but the file content being modified from a starting nonce).

vhong

sr. member

Activity: 361

Merit: 250

Quote from: overdozedCEO on June 06, 2016, 06:31:27 AM

Quote from: crowetic on June 05, 2016, 05:40:44 PM

-[ANN]- Team Directional Announcement (for lack of a better term, lol...)

Hello everyone! Thank you for following the BURST thread, just wanted to give a head's up of sorts, to get people an idea of what is going on, and our plans for the near future here in the BURST team.

I am going to set a definitive date, for the announcement of the BURST roadmap, and new BURST front end services, including a new one that no one has seen ever! Something completely new, with a lot of room for moving forward which I'm very excited about, and there are going to be companies formed over some of them.

- The new BURST roadmap will be announced on Friday, the 10th, along with as many of our public facing sites as possible, which now it seems will be at least 3, and a new service we are offering.

- New BURST version will follow behind that, along with many additions to the roadmap in place as we get closer to those goals. Thanks!

I'm soooo excited =) this is gonna be big, I know it Wink

It will be interesting to see what's in store on the new roadmap. I can't wait!

overdozedCEO

full member

Activity: 213

Merit: 100

Quote from: crowetic on June 05, 2016, 05:40:44 PM

-[ANN]- Team Directional Announcement (for lack of a better term, lol...)

Hello everyone! Thank you for following the BURST thread, just wanted to give a head's up of sorts, to get people an idea of what is going on, and our plans for the near future here in the BURST team.

I am going to set a definitive date, for the announcement of the BURST roadmap, and new BURST front end services, including a new one that no one has seen ever! Something completely new, with a lot of room for moving forward which I'm very excited about, and there are going to be companies formed over some of them.

- The new BURST roadmap will be announced on Friday, the 10th, along with as many of our public facing sites as possible, which now it seems will be at least 3, and a new service we are offering.

- New BURST version will follow behind that, along with many additions to the roadmap in place as we get closer to those goals. Thanks!

I'm soooo excited =) this is gonna be big, I know it Wink

Propagandalf

sr. member

Activity: 312

Merit: 250

Quote from: CIYAM on June 05, 2016, 08:58:10 PM

Quote from: riskyfire on June 05, 2016, 05:33:03 PM

Can you provide a example of how this might be used in the real world and what the benefit would be?

Would the file have to be generated for the task and in the same way that plotting is done? or would it be possible to use a drive/file of existing data and use that as you've described instead of creating plots?

I would think that existing files would be able to be used (the benefit being that there is no need to "plot" as an activity) although that might depend upon whether or not the file content should be encrypted (the reason you might want to do that is to avoid any potential issues about illegal/immoral content).

A simple purpose would be a "shared backup" system - and of course if you shared encryption keys for specific files then it could be used more like a P2P file sharing system.

If I understand you correctly, will such a modification allow us to use existing files on a drive without "locking" them to the mining process? If so, will that not lead to a free-for-all for all huge data centres around the world who can then mine while still hosting server space? I believe dedicating free space to plotting/mining has so far been a deterrent to those players.

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Quote from: riskyfire on June 05, 2016, 05:33:03 PM

Can you provide a example of how this might be used in the real world and what the benefit would be?

Would the file have to be generated for the task and in the same way that plotting is done? or would it be possible to use a drive/file of existing data and use that as you've described instead of creating plots?

I would think that existing files would be able to be used (the benefit being that there is no need to "plot" as an activity) although that might depend upon whether or not the file content should be encrypted (the reason you might want to do that is to avoid any potential issues about illegal/immoral content).

A simple purpose would be a "shared backup" system - and of course if you shared encryption keys for specific files then it could be used more like a P2P file sharing system.

crowetic

legendary

Activity: 2282

Merit: 1072

https://crowetic.com | https://qortal.org

-[ANNouncement]- BURSTeam BONUS payout complete!

Thank you for holding the asset, and your patience!

Code:

BURSTeam (14092376023955917604) Total found assets: 1000000, Assets to be distributed: 700000
Summary of proposed distribution of  250000BURST to 31
Based on asset holders at timestamp 57444989 (Sun, 20 Sep 2015 08:56:29 GMT)
----------------------
Number of assets, Account, Payout amount
188000, BURST-ACGB-YGHQ-G9ZL-5XD7U, 67142.85714286
105509.9, BURST-KKZA-XK7H-8YZ5-BKR87, 37682.10714286
80000, BURST-GM36-F7K7-XWKB-8MVH6, 28571.42857143
78000, BURST-7LPN-5UJU-L2MY-2SBKS, 27857.14285714
60000, BURST-DRY4-5Y27-UYDW-7956D, 21428.57142857
40000, BURST-GGPX-PP5S-LAGP-CBGCU, 14285.71428571
21234, BURST-DC8Y-UL75-FBZX-FM87U, 7583.57142857
20000, BURST-YW8Q-QJBC-M4T7-5XJE9, 7142.85714286
20000, BURST-JBLU-GNWQ-4DMK-EKCGC, 7142.85714286
19251, BURST-UX8P-CTNS-BVJG-9HTZJ, 6875.35714286
17385, BURST-ZEWG-V3ZY-WKL8-6V4RM, 6208.92857143
16669, BURST-TFAW-9FYW-GCXH-3A2AP, 5953.21428571
10000, BURST-K48W-F6TF-LQJW-FHR6A, 3571.42857143
5000, BURST-GC5N-HHD8-F5LD-BJFN3, 1785.71428571
4000, BURST-3BT5-6RGK-3TQL-GUAJ9, 1428.57142857
4000, BURST-WXSL-JFPN-5VBN-2N35S, 1428.57142857
3000, BURST-P6ZR-UMNC-P42F-8GRH5, 1071.42857143
2250, BURST-F36V-WLJC-UEAP-ERBE8, 803.57142857
2000, BURST-HCWT-AEZ2-GDVH-5UDFH, 714.28571429
2000, BURST-QNE2-ET5Q-CPX5-335BW, 714.28571429
1200, BURST-FWJ4-2VSS-BJT6-2T4HN, 428.57142857
100, BURST-9X5F-CMHL-9YJB-HKY3K, 35.71428571
100, BURST-YVM6-F388-G9ST-6S5Z9, 35.71428571
100, BURST-2QJP-325P-CSV5-3SG92, 35.71428571
90, BURST-LU3K-L8T7-3C66-63W5K, 32.14285714
50, BURST-KT3E-K7V5-Z5WQ-CBJN8, 17.85714286
45, BURST-GJPB-MV39-ZFEL-6PZDL, 16.07142857
10, BURST-K4WR-JWNT-2LUA-BX9X9, 3.57142857
5.6, BURST-8UNS-AUA4-6MHJ-HTFBG, 2
0.4, BURST-YMMH-ZSVJ-VDJF-H25VF, 0.14285714
0.1, BURST-LTFR-GXFS-3V25-9CD4X, 0.03571429

crowetic

legendary

Activity: 2282

Merit: 1072

https://crowetic.com | https://qortal.org

Quote from: CIYAM on June 05, 2016, 11:04:40 AM

Recently I was thinking about how to improve the concept behind Burst and realised that work that I have already done with my own project could help (in particular the CIYAM blockchain protocol's "chk" command is relevant).

The concept would basically be a "proof of storage" but it could be tied to any file (rather than "plots" of effectively random data).

As a simple illustration imagine that we have some file (xyz.mp3 for example). The SHA256 hash of this file's content could be used to identify it - but now we do something a little more interesting.

We start with a nonce that then is used as a starting point to hash the file content with - you would publish the original hash and the nonce and the new hash (with the latter needing to be verified by those that have the original file).

Note that it would not be possible to compute the final hash without actually having the entire file stored (as the file's hash isn't relevant beyond identifying it).

This could be used to form a new sort of proof that would allow the file content to be not random "rubbish" but in fact perhaps useful shared files.

Thank you for this, CIYAM, I have provided this post to the dev team, to see what they have to say on this. I think it would be very interesting indeed, if we could implement something of this nature. Thanks again man!

crowetic

legendary

Activity: 2282

Merit: 1072

https://crowetic.com | https://qortal.org

-[ANN]- Team Directional Announcement (for lack of a better term, lol...)

Hello everyone! Thank you for following the BURST thread, just wanted to give a head's up of sorts, to get people an idea of what is going on, and our plans for the near future here in the BURST team.

I am going to set a definitive date, for the announcement of the BURST roadmap, and new BURST front end services, including a new one that no one has seen ever! Something completely new, with a lot of room for moving forward which I'm very excited about, and there are going to be companies formed over some of them.

- The new BURST roadmap will be announced on Friday, the 10th, along with as many of our public facing sites as possible, which now it seems will be at least 3, and a new service we are offering.

- New BURST version will follow behind that, along with many additions to the roadmap in place as we get closer to those goals. Thanks!

riskyfire

sr. member

Activity: 275

Merit: 250

Quote from: CIYAM on June 05, 2016, 11:04:40 AM

Recently I was thinking about how to improve the concept behind Burst and realised that work that I have already done with my own project could help (in particular the CIYAM blockchain protocol's "chk" command is relevant).

The concept would basically be a "proof of storage" but it could be tied to any file (rather than "plots" of effectively random data).

As a simple illustration imagine that we have some file (xyz.mp3 for example). The SHA256 hash of this file's content could be used to identify it - but now we do something a little more interesting.

We start with a nonce that then is used as a starting point to hash the file content with - you would publish the original hash and the nonce and the new hash (with the latter needing to be verified by those that have the original file).

Note that it would not be possible to compute the final hash without actually having the entire file stored (as the file's hash isn't relevant beyond identifying it).

This could be used to form a new sort of proof that would allow the file content to be not random "rubbish" but in fact perhaps useful shared files.

Sounds very interesting, though to be honest its above my technical understanding of Burst. I found this part of particular interest ""proof of storage" but it could be tied to any file (rather than "plots" of effectively random data)."

Can you provide a example of how this might be used in the real world and what the benefit would be?

Would the file have to be generated for the task and in the same way that plotting is done? or would it be possible to use a drive/file of existing data and use that as you've described instead of creating plots?

CIYAM

legendary

Activity: 1890

Merit: 1086

Ian Knowles - CIYAM Lead Developer

Recently I was thinking about how to improve the concept behind Burst and realised that work that I have already done with my own project could help (in particular the CIYAM blockchain protocol's "chk" command is relevant).

The concept would basically be a "proof of storage" but it could be tied to any file (rather than "plots" of effectively random data).

As a simple illustration imagine that we have some file (xyz.mp3 for example). The SHA256 hash of this file's content could be used to identify it - but now we do something a little more interesting.

We start with a nonce that then is used as a starting point to hash the file content with - you would publish the original hash and the nonce and the new hash (with the latter needing to be verified by those that have the original file).

Note that it would not be possible to compute the final hash without actually having the entire file stored (as the file's hash isn't relevant beyond identifying it).

This could be used to form a new sort of proof that would allow the file content to be not random "rubbish" but in fact perhaps useful shared files.

Topic: [ANN] -NEW BURST OP- MINE ANY FREE SPACE-(HDD MINING)- ATs, AE, P2P MARKET+MORE! - page 112. (Read 346529 times)