Author

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

hero member
Activity: 539
Merit: 500
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.
sr. member
Activity: 256
Merit: 250
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
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
sr. member
Activity: 302
Merit: 250
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! 
full member
Activity: 213
Merit: 100
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?
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

/
full member
Activity: 213
Merit: 100
I dropped my bounty-signature of some random coin to support the devs lil bit
sr. member
Activity: 312
Merit: 250
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.  Smiley
full member
Activity: 213
Merit: 100
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
member
Activity: 112
Merit: 10
Yahoo new road map and on my birthday too! Kinda like a birthday present lol
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
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).
sr. member
Activity: 361
Merit: 250
-[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. Smiley


- 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!
full member
Activity: 213
Merit: 100
-[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. Smiley


- 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
sr. member
Activity: 312
Merit: 250
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.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
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.
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
legendary
Activity: 2282
Merit: 1072
https://crowetic.com | https://qortal.org
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!
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. Smiley


- 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!
sr. member
Activity: 275
Merit: 250
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?
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.
Jump to: