Propagandalf
|
|
June 05, 2016, 03:48:16 PM |
|
Just finished plotting my new 5 TB drive, bringing me to a total of 6.5 TB in plots. Feels good!
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
June 05, 2016, 04:04:40 PM |
|
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.
|
|
|
|
riskyfire
|
|
June 05, 2016, 10:33:03 PM |
|
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?
|
|
|
|
crowetic (OP)
Legendary
Offline
Activity: 2282
Merit: 1072
https://crowetic.com | https://qortal.org
|
|
June 05, 2016, 10: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!
|
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▒ ▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▒ ▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓ ▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓ ▒▒▒▒▒▒ ▓▓▓▓▓▓▒ ▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓ ▒▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▒ ▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▒ ▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒ ▓▓▓▓▓▓▒ ▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓
| ORTAL
| .⊙.Web and Application hosting. ⊙ decentralized infrastructure .⊙.leveling and voting.
| Founder/current dev group facilitator |
[/td][/tr][/table] [/table]
|
|
|
crowetic (OP)
Legendary
Offline
Activity: 2282
Merit: 1072
https://crowetic.com | https://qortal.org
|
|
June 05, 2016, 10:44:17 PM |
|
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!
|
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▒ ▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▒ ▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓ ▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓ ▒▒▒▒▒▒ ▓▓▓▓▓▓▒ ▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓ ▒▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▒ ▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▒ ▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒ ▓▓▓▓▓▓▒ ▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓
| ORTAL
| .⊙.Web and Application hosting. ⊙ decentralized infrastructure .⊙.leveling and voting.
| Founder/current dev group facilitator |
[/td][/tr][/table] [/table]
|
|
|
crowetic (OP)
Legendary
Offline
Activity: 2282
Merit: 1072
https://crowetic.com | https://qortal.org
|
|
June 05, 2016, 10:58:15 PM |
|
-[ANNouncement]- BURSTeam BONUS payout complete!Thank you for holding the asset, and your patience!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
|
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▒ ▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▒ ▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓ ▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓ ▒▒▒▒▒▒ ▓▓▓▓▓▓▒ ▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓ ▒▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▒ ▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▒ ▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▒ ▓▓▓▓▓▓▒ ▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▒ ▒▓▓▓▓▓▓ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ▒▓▓▓▓▓▓▓▓▓▓▓▓▓▓
| ORTAL
| .⊙.Web and Application hosting. ⊙ decentralized infrastructure .⊙.leveling and voting.
| Founder/current dev group facilitator |
[/td][/tr][/table] [/table]
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
June 06, 2016, 01:58:10 AM |
|
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.
|
|
|
|
Propagandalf
|
|
June 06, 2016, 08:23:49 AM |
|
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.
|
|
|
|
overdozedCEO
|
|
June 06, 2016, 11:31:27 AM |
|
-[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
|
|
|
|
vhong
|
|
June 06, 2016, 12:21:19 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 It will be interesting to see what's in store on the new roadmap. I can't wait!
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
June 06, 2016, 03:19:25 PM Last edit: June 06, 2016, 03:29:30 PM by CIYAM |
|
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).
|
|
|
|
tross
Member
Offline
Activity: 112
Merit: 10
|
|
June 06, 2016, 04:51:42 PM |
|
Yahoo new road map and on my birthday too! Kinda like a birthday present lol
|
|
|
|
overdozedCEO
|
|
June 06, 2016, 07:48:01 PM |
|
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
|
|
|
|
Propagandalf
|
|
June 06, 2016, 09:08:57 PM |
|
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
|
|
June 06, 2016, 10:10:16 PM |
|
I dropped my bounty-signature of some random coin to support the devs lil bit
|
|
|
|
drbobbo
Newbie
Offline
Activity: 41
Merit: 0
|
|
June 06, 2016, 10: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
/
|
|
|
|
overdozedCEO
|
|
June 06, 2016, 10:15:44 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?
|
|
|
|
daWallet
|
|
June 06, 2016, 10:27:43 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!
|
github/dawallet Burst Client for Win & Burstcoin.biz
|
|
|
Vin
Legendary
Offline
Activity: 1166
Merit: 1015
|
|
June 06, 2016, 10:54:26 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
|
|
|
|
callmejack
|
|
June 06, 2016, 11:35:31 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.
|
|
|
|
|