[ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000

[yeponlyone]

Okay, what if we make the following modifications...


1. The cap stays, but coins are added to its total.

2. Rewards are still raised, and decline in reward is lowered. Reward goes to 15k/block now, and reward decline changes to match bitcoin's halving times, by going to 1.455% per month.

3. Transaction fees go up too, minimum goes to 2 or more BURST per transaction, until we believe we can lower it again when there are many more transactions in the network.



This gives incentive for miners to jump back in now and make network bigger again, during this we work our asses off and get the market mods done, mixer AT integrated, etc. Make the market browser better with categories and searchable, etc. Hire a PR company to promote the decentralized market, and get many more users to it.

Get more assets up and running, and work hard to get investors at the same time.

Nice, but some devfund most be established to cover expenses. I think it makes sense that a small part of each block should be devoted to this. Not anywhere near 10% but some.

Fees can also be made relative to the sum sent: Are you sending large amounts, it's not unreasonable with higher fees.

Right, I did forget that part, there will still be a dev fund, and I think 10% is fair, but we can go lower, maybe 8? But it isn't just a dev fund, you can think of it as a future promo, development and just an overall futures fund for the coin...

It will allow us to HIRE devs to do whatever we need, hire graphic designers, whatever the coin needs! I don't see why everyone expects the few members who already put a ton of work into everything to pay for all of this out of their pockets as well, I'm a fairly large miner and I would have absolutely no issue with this percentage going to further the coin.

Then when we can get our p2p voting system implemented, the people with more coin can have more power in helping to decide how that money is spent. So it isn't like there will be an overlord who will decide everything. There will be voting and we will all make decisions, and of course, the ones with a larger stake and thus more invested into the coin will have more of a say. I feel this is ultimately extremely fair.

Sure, but I think you have to consider how a "devfund" will be perceived both by the community at large, the BURST community and newcomers. Words like "tax" and "premine" have already been used... and in my world, words like that do not have positive connotation. Consider comments on a premine of 8 percent...

No matter which percentage is implemented at first, it needs to be extremely well-explained and argumented.

From my point of view, a p2p voting system is great if it can be implemented, but it still is the chosen number that will be highlighted in discussions. One counter-argument here to a high percentage like one 8th of each block, is that it doesn't properly consider the expected value-increase of BURST. 8 percent can be quite a lot of money in two years, and quite ridiculous in double that time.

If PoC catches on as we hope and we'll see an opposite trend to what we seen this year in popularity the coming years, the accumulated amount could simply become more than you can spend, more or less, without being "careless", paying too much, hiring too many, promote too often to be reasonable. If the fund would become that big, it could also become sort of a target where big holders get together to get their "investments ideas" through, like giving money to the most biggest holders...

I'd suggest to lower the percentage more than to 8, but also in the argumentation for the system add that money from the devfund - if it becomes too big due to value-increase - funding also will go back to the community, miners and holders in certain ways.

Such ways could be that the fund can be used to have a "sale" in the market-place, make payments to crowdfunding projects, add money to lotteries or even charity, etc.

If doing so, I think it's appropriate to change the name of the "devfund" to the "BURST foundation" to highlight a possible wider-usage of the funds.

[pinballdude]

I'd like to add my comments to the discussion on burst.

I've not been very active on here so I'll start by saying a little about myself.

I have been mining burst for quite a while. Not from the very beginning but from a few weeks after it started. I am only mining with disks that were laying around unused at home. I have not sold any coins since October last year so I am holding a decent amount. I am mining solo but I have mined on devs v1 and v2 pools. My miners are all running on fedora but I have mined in the past on XP and w7. I am a professional sw engineer and I have been writing code since the sixties.

OK, that is me, this is what I have to say:

We should not change the way in which block rewards are allocated. We all knew what the rewards were when we started out and we accepted that but there is a stronger reason than just that. If an outsider looks at the coin, what will they think if the elite few running the coin feel that it is OK to change something that basic just one year in? It does not look like the trustworthy foundation that is needed. The same goes for the idea of a dev fund. The coin's elite just arbitrarily saying that they will have ten percent off the top because they want it? What might they do next? This will deter newcomers to the coin whether they are miners, investors or developers.

We should not be looking for some fairy godmother lead developer. First of all as crowetic discovered, somebody like that is hard to find. Furthermore, the coin would then be hostage to that new lead dev's personal situation and wishes. The existing team should work to build a group of devs who can all put in a little time and the core team should work hard to attract and encourage such people.

Some months ago, I made a post on here about using burst as a storage network. Burst is better than the other coins that are trying to do this. We have miners with lots of storage who could repurpose their disk space between plots and storage as the market required. We also have a coin with ATs which could be used to govern the storage contracts. We could use them to make sure not only that clients can pay for storage and that disk farmers can be rewarded but also to ensure that neither party can carry out a "nothing at stake" attack. In my earlier post, I offered to pitch in with development effort to help set that up but none of the coin's core team responded. My offer is still open and I would suggest to the core team that they should consider that and any other offers.

@Irontiga: I believe that you are in godzone. If you are in Ak, perhaps we could meet and chat and if you think that I can help out, you can talk to the rest of the core team.

I would propose the following as action items for the short term:

1) Try to recruit developers who will commit a few hours of their time as and when they can. Create some kind of on-boarding process for these volunteers such as getting the sources off github, making some trivial change and rebuilding all of the files that would make up a release. Just to check that they have the basic technical ability to contribute. Then establish a set of procedures for code reviews before changes to the burst software are accepted. Document that whole process.

2) Build a set of unit tests. We need these if we are going to have a number of devs working on different parts of the code. Any dev who wants to get involved should start there. It's not going to add features but it will make it a lot easier and safer to roll out new features in the future.

3) Setup a group to thrash out a roadmap of new features that will be implemented by the new dev-team over the next 12 months.

4) Perform a review of burst's POC algorithms. I understand that the security of these has been questioned so we should address that. I have a fair understanding of cryptography and I have access to people who work at the bleeding edge in that field so I can help there.

5) Lighten up on the abuse. Name calling and the use of disrespectful miss-spellings of folk's usernames should stop. It does not make the coin any better and it does not make people look any better if they do it.

I have not written anything about PR or white-papers but if we got through the five points above we would have lots to tell the world about and most of what we would need for a white-paper would have been sorted out.

That's it.

What he said, except i only started developing software in the 80s

I also think we have an opportunity window to make a file system on top of or driven by burst. I think such a thing would be outright revolutionary and could drive up the price of burst 10 or 20 fold over a few months. If we can get an anonymous decentralized encrypted file storage service online, it would be even more valuable than e.g. dropbox. Not easy to create, but we have the advantage of having payment system, decentralized network, and several terabytes of storage already. Not a bad start.

[notabeliever]

Windows 10?

What wallets and miners works on windows 10?

[haitch]

Windows 10?

What wallets and miners works on windows 10?

The java wallet works fine, so does the Windows Wallet. For miners I've used both Blagos and Luxe's GPU Miner.

H.

[Irontiga]

Okay, what if we make the following modifications...


1. The cap stays, but coins are added to its total.

2. Rewards are still raised, and decline in reward is lowered. Reward goes to 15k/block now, and reward decline changes to match bitcoin's halving times, by going to 1.455% per month.

3. Transaction fees go up too, minimum goes to 2 or more BURST per transaction, until we believe we can lower it again when there are many more transactions in the network.



This gives incentive for miners to jump back in now and make network bigger again, during this we work our asses off and get the market mods done, mixer AT integrated, etc. Make the market browser better with categories and searchable, etc. Hire a PR company to promote the decentralized market, and get many more users to it.

Get more assets up and running, and work hard to get investors at the same time.

1. Can agree to.

2. No, not 15K. Raise it to where it would be if it had declined at 1% per month - around 8,500. At 1% per month we get annual deflation of 11.4% and require the price to raise 12% to maintain value. At the 5% per month we were getting 46% deflation, and needed 85% annual price increase to maintain value.

3) No need to change transaction fees.

H.

Noo, this is unfair to initial investors and miners. The only fair way to do it is to leave it at current reward or change the decrease to 1% or whatever, or leave it as it is. It's not fair to raise the reward from where it is now, as then the miners mining for the past few months have got a raw deal. Total cap can be increased i suppose. Just hard with how price has moved downwards....I really think we should focus not on burst's poc core, but rather on file sharing and an awesome wallet.

[pinballdude]

Thank you for the comments, but I disagree on the modification comment. We noticed, that after a year, the reward decrease happened too fast for what else was going on in the coin.

This is where we disagree. I don't think the reward decrease is happening too fast. Rather, the price is coming down too fast because we issue too many coins, so the decrease should perhaps have been even faster. But it is close to an insult against everyone who has worked with burst up till now, to change a vital part like that. Let the coins be distributed as was originally set up, or lets make a new coin with a better distribution, and let them compete.

The ability to modify it a little, and make it be able to work out better over an extended period of time would be the goal here, while allowing miners to have either more profit if they dump, or more long term profit if they don't.

if we reward more now, but less later ( get the rest of the coins out the door faster ) then the mine-and-sell miners might dump even more now, driving the price down further, but when we run out of coins later on, the price will go up a lot, as the selling pressure from mine-and-dump'ers  will go away.  This is not really a big advantage for anyone i think, and it still introduces risk with the coin investor wise, as the inflation rules change in midair and investors hate that.

if we add coins to the reward on an ongoing basis, the current BURST holdings are worth a lot less than they used to be, and BURST will not be a store of value.  mine-and-dump miners will have more BURST to dump, and investors will not want to buy BURST that go down in price all the time, even more than it has done up till now, so this solution is really bad. The only one making money here is the mine-and-dump miner - he gets to sell his BURST before the inflation of the newly issued coin is spread through the economy. Very bad.

Also, the tax wouldn't go to a single person, and discussions would happen with the community as far as ideas on how to spend the money, multi-sig held, etc. Maybe even an AT controlled account. There are many ways we can setup this type of thing.

But the tax is taken involuntarily from users, i would prefer a company approach where the ones who pay in, will get money back when the company makes money. Again, you are changing the rules on what should be a fixed setup, so people will shy away from holding BURST as a store of value, making BURST price go down significantly.

The idea of an open community development project makes a lot of sense as it IS open source afterall, so that is what we're going to do at this very point in time, people can clone the git, make their suggested changes, and post for approval, then we can implement into a new main git when a few coders have approved it and it all looks good to go.

I would love a review of the algo. Please do this if you can.

Also, get as many devs as you can, greatly appreciated, then if we want to go back to a core team style development, we can do that. But for now, with all the reactions I got when suggesting the structure I did, open community development is where we will be until something better comes along.

Is it only burstcoin that have write access to the burstcoin git.  I think it is more than him. If that is correct then we already have our core team, burstcoin and whoever else have write control. We just have to write up a guide for development, and make the current core dev team agree on the guidelines.  Guidelines should also mention how a developer might become member of the core team if he/she so wishes.

if it is only burstcoin that have write access, then we would probably need to make a fork/clone of the burstcoin repo and declare that the new main repo. I would very much prefer to wait until we hear from burstcoin instead of doing that, it would be so much nicer to have burstcoin in the core team, and have several people having write access to the main repository. A fork  / clone looks like a hostile takeover, and nobody is hostile, everyone loves burstcoin and the work done, it's just that we miss burstcoin so much right now, and would love to help out getting stuff done.

[pinballdude]

Windows 10?

What wallets and miners works on windows 10?

I am running my own version of the java wallet, but the original one works just fine too.

I am running my own version of the orignal java miner on windows 10 10240 and 10532 and it works fine with no problems whatsoever. The original one works fine too, my modifications are purely diagnostic and display.

As for plotting i use something called wplotgenerator.exe  it uses the CPU but with 8 cores at 4Ghz it is fairly fast anyways.

W7 had problems reading a lot of drives at the same time, and thrashed its memory, it seems like W10 is a lot better at managing things. I can work at this machine even though it is mining 24TB, i hardly ever notice a slowdown. This PC is quite powerful though, 8 cores, 4Ghz, 32GB memory, decent GPU etc. W7 would crash doing the same.

W10 still has a horribly unreliable time synchronization built in. i use the program NetTime on my pc's to keep them +/- 1 second from the correct time. Correct time is vital for burst mining, you loose out big if your pc is 30 seconds ahead or behind.

[crowetic]

I like the company idea, but wouldn't we end up in pretty close to the same situation with the need for investors?

[pinballdude]

I like the company idea, but wouldn't we end up in pretty close to the same situation with the need for investors?

You need to convince investors that the company will make money down the line.
If the investors can buy BTC and not really have to fiddle with BURST, you have a somewhat larger audience, however their asset holdings should probably be registered in the BURST chain,so an investor would need help to have a wallet established with a secure password that has not been leaked. ( or a thief could move the assets off the account )

The great thing about the company is that the company is seperate from the core dev group. The core dev group can still make sure BURST is stable and true to whatever the larger group of users want. The company owners can speed up development of services and whatever BURST stuff is needed to establish such services, and make money off the products. Company could also run mining pools or websites related to burst, if the company thinks such websites could be profitable, or somehow raise the burst price enough to warrant development.

Suppose the company developed file storage in burstcoin.  The dev team would then still have the final say about if and when the file storage stuff is relased in burstcoin, but the feature is done, and the company will be first in line to profit off such a feature, as the company has the best tech insight, and have had time to develop ways to profit from the new infrastructure. The company might release a file storage mining pool close to day 1, and offer to lease the source for the pool to other people who want to own a file storage pool. revenues from FS pool and lease to others could then over time generate a nice ROI of the company money spent on software development.

Suppose the company developed coin anonymization support in BURST.  as soon as the new version was released, the company would have a website ready and be marketing it to users. Company would have a head start with the stuff it sponsors, as it has the knowledge and of course it might have had influence on the feature set so that the capabilities match well with company needs.

With a good story, and with marketing both inside and outside burst community, you might have an easy sell.

Basically, funding a company that will drive development of services and products that utilize BURST, a company dedicated to grow and make money by being first mover in new technologies. Opportunity for shareholders to get in at a low price, in a company that could be a major player in select areas like encrypted anonymouse file storage, areas like crypto finance, areas like automated transactions - bleeding edge stuff..

[crowetic]

I like the company idea, but wouldn't we end up in pretty close to the same situation with the need for investors?

You need to convince investors that the company will make money down the line.
If the investors can buy BTC and not really have to fiddle with BURST, you have a somewhat larger audience, however their asset holdings should probably be registered in the BURST chain,so an investor would need help to have a wallet established with a secure password that has not been leaked. ( or a thief could move the assets off the account )

The great thing about the company is that the company is seperate from the core dev group. The core dev group can still make sure BURST is stable and true to whatever the larger group of users want. The company owners can speed up development of services and whatever BURST stuff is needed to establish such services, and make money off the products. Company could also run mining pools or websites related to burst, if the company thinks such websites could be profitable, or somehow raise the burst price enough to warrant development.

Suppose the company developed file storage in burstcoin.  The dev team would then still have the final say about if and when the file storage stuff is relased in burstcoin, but the feature is done, and the company will be first in line to profit off such a feature, as the company has the best tech insight, and have had time to develop ways to profit from the new infrastructure. The company might release a file storage mining pool close to day 1, and offer to lease the source for the pool to other people who want to own a file storage pool. revenues from FS pool and lease to others could then over time generate a nice ROI of the company money spent on software development.

Suppose the company developed coin anonymization support in BURST.  as soon as the new version was released, the company would have a website ready and be marketing it to users. Company would have a head start with the stuff it sponsors, as it has the knowledge and of course it might have had influence on the feature set so that the capabilities match well with company needs.

With a good story, and with marketing both inside and outside burst community, you might have an easy sell.

Basically, funding a company that will drive development of services and products that utilize BURST, a company dedicated to grow and make money by being first mover in new technologies. Opportunity for shareholders to get in at a low price, in a company that could be a major player in select areas like encrypted anonymouse file storage, areas like crypto finance, areas like automated transactions - bleeding edge stuff..

The more I think about it, the more I like it, and I would very much enjoy setting up and running something like this. There would be need for initial investment for promotion and I could do as much twitter and forum promotion in various areas of this forum to promote it.

Do you think this would have to be another separate company completely? Or could I wrap it together as part of my existing company something like I did with ByteEnterprises?

The whole thing I keep thinking about though, is the idea that we'd still be in need of investors, however, it shouldn't be THAT hard to find people who'd be more willing to invest in a company than a particular coin, even if that company is working almost solely for that particular coin's technology. The company wouldn't necessarily be fully limited to that coin either. If there WERE a clone that came out, said company would be most likely interested in that as well, as the technology would be available there as well.

very interesting. I wonder if this could be something I could make happen.

One thing though, is that the stuff we're working with is open source, so what would keep others from just ripping off the ideas we paid to have developed and doing it themselves? Not quite the same as the company you formed for the idea you mentioned.

[Elmit]

Okay, what if we make the following modifications...


1. The cap stays, but coins are added to its total.

2. Rewards are still raised, and decline in reward is lowered. Reward goes to 15k/block now, and reward decline changes to match bitcoin's halving times, by going to 1.455% per month.

3. Transaction fees go up too, minimum goes to 2 or more BURST per transaction, until we believe we can lower it again when there are many more transactions in the network.



This gives incentive for miners to jump back in now and make network bigger again, during this we work our asses off and get the market mods done, mixer AT integrated, etc. Make the market browser better with categories and searchable, etc. Hire a PR company to promote the decentralized market, and get many more users to it.

Get more assets up and running, and work hard to get investors at the same time.

1. Can agree to.

2. No, not 15K. Raise it to where it would be if it had declined at 1% per month - around 8,500. At 1% per month we get annual deflation of 11.4% and require the price to raise 12% to maintain value. At the 5% per month we were getting 46% deflation, and needed 85% annual price increase to maintain value.

3) No need to change transaction fees.

H.

Noo, this is unfair to initial investors and miners. The only fair way to do it is to leave it at current reward or change the decrease to 1% or whatever, or leave it as it is. It's not fair to raise the reward from where it is now, as then the miners mining for the past few months have got a raw deal. Total cap can be increased i suppose. Just hard with how price has moved downwards....I really think we should focus not on burst's poc core, but rather on file sharing and an awesome wallet.

More or less the coin is dead and we can change whatever is useful.
I agree with the changes!

[haitch]

Okay, what if we make the following modifications...


1. The cap stays, but coins are added to its total.

2. Rewards are still raised, and decline in reward is lowered. Reward goes to 15k/block now, and reward decline changes to match bitcoin's halving times, by going to 1.455% per month.

3. Transaction fees go up too, minimum goes to 2 or more BURST per transaction, until we believe we can lower it again when there are many more transactions in the network.



This gives incentive for miners to jump back in now and make network bigger again, during this we work our asses off and get the market mods done, mixer AT integrated, etc. Make the market browser better with categories and searchable, etc. Hire a PR company to promote the decentralized market, and get many more users to it.

Get more assets up and running, and work hard to get investors at the same time.

1. Can agree to.

2. No, not 15K. Raise it to where it would be if it had declined at 1% per month - around 8,500. At 1% per month we get annual deflation of 11.4% and require the price to raise 12% to maintain value. At the 5% per month we were getting 46% deflation, and needed 85% annual price increase to maintain value.

3) No need to change transaction fees.

H.

Noo, this is unfair to initial investors and miners. The only fair way to do it is to leave it at current reward or change the decrease to 1% or whatever, or leave it as it is. It's not fair to raise the reward from where it is now, as then the miners mining for the past few months have got a raw deal. Total cap can be increased i suppose. Just hard with how price has moved downwards....I really think we should focus not on burst's poc core, but rather on file sharing and an awesome wallet.

More or less the coin is dead and we can change whatever is useful.
I agree with the changes!

If Elmit is in favor, then I withdraw all my previous proposals and will reconsider my position.

In the meantime, anyone who holds Income asset and has lost faith, please sell - I have a buywall up at the initial published price.

Thanks.

H.

[allZuckedUp]

hiya folks, it's me again with another random technical question...

So, I've got myself 4T spread across 4 disks, and I've plotted and optimized and such (3.2T worth of nonces), and I'm mining away happily on cryptomining.farm using Uray's miner r4.  In the past, I had no problems getting dcct's plotter and optimizer to work, but with a few different pools, I was unable to get the dcct miner to work, thus why I found myself using Uray's miner.  Uray's miner is working ok, BUT, I've organized my disks into 50G plotfiles (16 files per disk), and when it gets a block, it seems to try to read all plot files across all disks at once, basically blowing up all disks at once, and making the machine put up massive load averages, while just basically waiting for IO.  (I was using an old thin client, turned low power "server" to mine, but to try to help this, I'm now mining on 8 threads/4G RAM dedicated to the miner, and it's still melting whatever box I mine on)

So, I guess my question is there any way to configure Uray's miner read the plots sequentially, or one disk at a time?  Or, do any of the other cpu miners out there do that?  It would seem I could get the same sort of speed per round, without beating the crap out of my machine that way...

I can't be the first to observe and/or request this, right?

Thanks.

[haitch]

hiya folks, it's me again with another random technical question...

So, I've got myself 4T spread across 4 disks, and I've plotted and optimized and such (3.2T worth of nonces), and I'm mining away happily on cryptomining.farm using Uray's miner r4.  In the past, I had no problems getting dcct's plotter and optimizer to work, but with a few different pools, I was unable to get the dcct miner to work, thus why I found myself using Uray's miner.  Uray's miner is working ok, BUT, I've organized my disks into 50G plotfiles (16 files per disk), and when it gets a block, it seems to try to read all plot files across all disks at once, basically blowing up all disks at once, and making the machine put up massive load averages, while just basically waiting for IO.  (I was using an old thin client, turned low power "server" to mine, but to try to help this, I'm now mining on 8 threads/4G RAM dedicated to the miner, and it's still melting whatever box I mine on)

So, I guess my question is there any way to make Uray's miner read the plots sequentially, or one disk at a time?  Or, do any of the other cpu miners out there do that?  It would seem I could get the same sort of speed per round, without beating the crap out of my machine that way...

I can't be the first to observe and/or request this, right?

Thanks.

I recall that if you specify the drives as C:\+D:\+E:\ it will read the drives sequentially instead of simultaneously - but I don't recall if that was the native miner or one of the third parties - probably Blagos.

[allZuckedUp]

hiya folks, it's me again with another random technical question...

So, I've got myself 4T spread across 4 disks, and I've plotted and optimized and such (3.2T worth of nonces), and I'm mining away happily on cryptomining.farm using Uray's miner r4.  In the past, I had no problems getting dcct's plotter and optimizer to work, but with a few different pools, I was unable to get the dcct miner to work, thus why I found myself using Uray's miner.  Uray's miner is working ok, BUT, I've organized my disks into 50G plotfiles (16 files per disk), and when it gets a block, it seems to try to read all plot files across all disks at once, basically blowing up all disks at once, and making the machine put up massive load averages, while just basically waiting for IO.  (I was using an old thin client, turned low power "server" to mine, but to try to help this, I'm now mining on 8 threads/4G RAM dedicated to the miner, and it's still melting whatever box I mine on)

So, I guess my question is there any way to make Uray's miner read the plots sequentially, or one disk at a time?  Or, do any of the other cpu miners out there do that?  It would seem I could get the same sort of speed per round, without beating the crap out of my machine that way...

I can't be the first to observe and/or request this, right?

Thanks.

I recall that if you specify the drives as C:\+D:\+E:\ it will read the drives sequentially instead of simultaneously - but I don't recall if that was the native miner or one of the third parties - probably Blagos.

Thanks!  
Well, except that I'm running Linux (I don't do windoze, personally or professionally), soooo anyway, no drive letters.

The disks are mounted as such... (df -h output)
Filesystem                Size  Used Avail Use% Mounted on
/dev/sdf1                 932G  801G  132G  86% /media/usb_drive0
/dev/sdg1                 932G  801G  132G  86% /media/usb_drive1
/dev/sdh1                 932G  801G  132G  86% /media/usb_drive2
/dev/sdi1                 932G  801G  132G  86% /media/usb_drive3

I'll work on giving some other miners a shot, and we'll see if I get any different results.  And please understand, I'm not bitching, it's actually working great, on my existing disk, I'm averaging like 600+ burst per day.  I'm just trying to improve this ugliness (you can really see where I went from optimizing to mining in the graph below), and hopefully not sacrifice good equipment by cooking it on the quest for burstcoin...



seems a bit much in terms of load... No?

Oh shiney!  Another question or two... my disks are all USB, not ideal, but I got the disks for free, so beggars can't be choosers.  The 4 1T disks are USB3, and plugged into a single USB3 hub.  The server in question actually has enough USB3 ports to plug in all 4 disks directly.  Considering the hypothetical speeds of USB3, should that matter?  Or, should I see greater performance if I plug all the disks directly into the box in your collective experiences?  

And lastly, and I apologize for this if it's been answered or documented, but my attempts at finding this have proven fruitless thus far... This question is for both the "standard" version of a mining pool for burst (I think that's Uray's V2, if I remember correctly), AND for the wallet/lockchain itself... API? RPC? Logfile?? Meaning, is there a methodology to query metrics about my mining? balances? transactions? etc. etc. I'd settle for launching the miner and wallet with a ">>" into a file, if burst echoed anything with friggin' timestamps!!  I'm a *NIX nerd by trade, and the wallet being written in java, AND the pool software seemingly not wanting to make a lot of standard information metrics available easily has been somewhat frustrating for me... I realize I'm the opposite of most, but I NEED my CLI damnit!  

Thanks again.  And sorry to ramble.

[Elmit]

hiya folks, it's me again with another random technical question...

So, I've got myself 4T spread across 4 disks, and I've plotted and optimized and such (3.2T worth of nonces), and I'm mining away happily on cryptomining.farm using Uray's miner r4.  In the past, I had no problems getting dcct's plotter and optimizer to work, but with a few different pools, I was unable to get the dcct miner to work, thus why I found myself using Uray's miner.  Uray's miner is working ok, BUT, I've organized my disks into 50G plotfiles (16 files per disk), and when it gets a block, it seems to try to read all plot files across all disks at once, basically blowing up all disks at once, and making the machine put up massive load averages, while just basically waiting for IO.  (I was using an old thin client, turned low power "server" to mine, but to try to help this, I'm now mining on 8 threads/4G RAM dedicated to the miner, and it's still melting whatever box I mine on)

So, I guess my question is there any way to make Uray's miner read the plots sequentially, or one disk at a time?  Or, do any of the other cpu miners out there do that?  It would seem I could get the same sort of speed per round, without beating the crap out of my machine that way...

I can't be the first to observe and/or request this, right?

Thanks.

I recall that if you specify the drives as C:\+D:\+E:\ it will read the drives sequentially instead of simultaneously - but I don't recall if that was the native miner or one of the third parties - probably Blagos.

Thanks!  
Well, except that I'm running Linux (I don't do windoze, personally or professionally), soooo anyway, no drive letters.

The disks are mounted as such... (df -h output)
Filesystem                Size  Used Avail Use% Mounted on
/dev/sdf1                 932G  801G  132G  86% /media/usb_drive0
/dev/sdg1                 932G  801G  132G  86% /media/usb_drive1
/dev/sdh1                 932G  801G  132G  86% /media/usb_drive2
/dev/sdi1                 932G  801G  132G  86% /media/usb_drive3

I'll work on giving some other miners a shot, and we'll see if I get any different results.  And please understand, I'm not bitching, it's actually working great, on my existing disk, I'm averaging like 600+ burst per day.  I'm just trying to improve this ugliness (you can really see where I went from optimizing to mining below), and hopefully not sacrifice good equipment by cooking it on the quest for burstcoin...



seems a bit much in terms of load... No?

Oh shiney!  Another question or two... my disks are all USB, not ideal, but I got the disks for free, so beggars can't be choosers.  The 4 1T disks are USB3, and plugged into a single USB3 hub.  The server in actually has enough USB3 ports to plug in all 4 disks directly.  Considering the hypothetical speeds of USB3, should that matter?  Or, should I see greater performance if I plug all the disks directly into the box in your collective experiences?  

And lastly, and I apologize for this if it's been answered or documented, but my attempts at finding this have proven fruitless thus far... This question is for both the "standard" version of a mining pool for burst (I think that's Uray's V2, if I remember correctly), AND for the wallet/lockchain itself... API? RPC? Logfile?? Meaning, is there a methodology to query metrics about my mining? balances? transactions? etc. etc. I'd settle for launching the miner and wallet with a ">>" into a file, if burst echoed anything with friggin' timestamps!!  I'm a *NIX nerd by trade, and the wallet being written in java, AND the pool software seemingly not wanting to make a lot of standard information metrics available easily has been somewhat frustrating for me... I realize I'm the opposite of most, but I NEED my CLI damnit!  

Thanks again.  And sorry to ramble.

We have up to 3 USB-3 hubs cascaded, works fine, because the disks are read sequently.
Linux is a good choice, I do the same.
What are you actually looking for?

I use screen or tmux to get the most out of it. I use in one window, the wallet, the miner:
cd
mv burstminer.log burstminer-2015-07-03=15-58
cd burst/burst-miner-r4/
./burstminer | ~/bin/prepend-date>> ~/burstminer.log

in the next window:
tail -f ~/burstminer.log | ~/bin/color-output


with ~/bin/prepend-date:
#!/bin/sh

while read LINE; do
  echo "$(date +%F\ %T): $LINE"
done


and ~/bin/color-output:

#!/bin/sh

sed -e 's/\bsuccess\b/\x1b[01;92m&\x1b[0m/' \
  -e 's/\bdays\b/\x1b[01;91m&\x1b[0m/' \
  -e 's/\b\confirmed\b/\x1b[01;94m&\x1b[0m/'


That works fine for me.
http://burst.mininghere.com

[allZuckedUp]

We have up to 3 USB-3 hubs cascaded, works fine, because the disks are read sequently.
Linux is a good choice, I do the same.
What are you actually looking for?

I use screen or tmux to get the most out of it. I use in one window, the wallet, the miner:
cd
mv burstminer.log burstminer-2015-07-03=15-58
cd burst/burst-miner-r4/
./burstminer | ~/bin/prepend-date>> ~/burstminer.log

in the next window:
tail -f ~/burstminer.log | ~/bin/color-output


with ~/bin/prepend-date:
#!/bin/sh

while read LINE; do
  echo "$(date +%F\ %T): $LINE"
done


and ~/bin/color-output:

#!/bin/sh

sed -e 's/\bsuccess\b/\x1b[01;92m&\x1b[0m/' \
  -e 's/\bdays\b/\x1b[01;91m&\x1b[0m/' \
  -e 's/\b\confirmed\b/\x1b[01;94m&\x1b[0m/'


That works fine for me.
http://burst.mininghere.com

Thank you, I like your little prepend script, I feel stupid for not thinking of something so simple... Annnnnd, I was going to write a wrapper to output via rsyslog, but I think you just made me lazy... I like it.

Anyway, my biggest problem is the disks... I can't see any evidence that they are read sequentially.  I have 64 plot files, of 50G each, spread evenly across the disks (16/disk).  And, from what I can tell, watching the disks IO, just looking at the lights, or even the seemingly random order of the "plot read done" statements the miner outputs... It seems to spin up all 64 plot files at once.  

That leads me to yet another related question.  Filesystem formats. When the box in basically burning itself up in "IO wait land", I notice the mount ntfs-3g process is eating up the cpu (not shocking considering it's seeking on those disks) So obviously I haven't given the disks native linux filesystems; have you found any greater performance formatting the disks ext4 or something?

[Elmit]

We have up to 3 USB-3 hubs cascaded, works fine, because the disks are read sequently.
Linux is a good choice, I do the same.
What are you actually looking for?

I use screen or tmux to get the most out of it. I use in one window, the wallet, the miner:
cd
mv burstminer.log burstminer-2015-07-03=15-58
cd burst/burst-miner-r4/
./burstminer | ~/bin/prepend-date>> ~/burstminer.log

in the next window:
tail -f ~/burstminer.log | ~/bin/color-output


with ~/bin/prepend-date:
#!/bin/sh

while read LINE; do
  echo "$(date +%F\ %T): $LINE"
done


and ~/bin/color-output:

#!/bin/sh

sed -e 's/\bsuccess\b/\x1b[01;92m&\x1b[0m/' \
  -e 's/\bdays\b/\x1b[01;91m&\x1b[0m/' \
  -e 's/\b\confirmed\b/\x1b[01;94m&\x1b[0m/'


That works fine for me.
http://burst.mininghere.com

Thank you, I like your little prepend script... Annnnnd, I was going to write a wrapper to output via rsyslog, but I think you just made me lazy... I like it.

Anyway, my biggest problem is the disks... I can't see any evidence that they are read sequentially.  I have 64 plot files, of 50G each, spread evenly across the disks (16/disk).  And, from what I can tell, watching the disks IO, just looking at the lights, or even the seemingly random order of the "plot read done" statements the miner outputs... It seems to spin up all 64 plot files at once.  

That leads me to yet another related question.  Filesystem formats. When the box in basically burning itself up in "IO wait land", I notice the mount ntfs-3g process is eating up the cpu (not shocking considering it's seeking on those disks) So obviously I haven't given the disks native linux filesystems; have you found any greater performance formatting the disks ext4 or something?

If you look at the mining log output, you will se, when the plots are read, also the lights go out sequentially.
ntfs-3g is annoying, but there I was too lazy to format it differently. Well. I did on one machine to ext4, but it had then less capacity. I was told that's because of the journalling system. We don't need to backup. If the disk is broken, plot it new! Therefore journalling system is also not necessary. I left it then on ntfs.

I put into /etc/fstab:

LABEL=SG-17-4T   /media/ronald/SG-17-4T   ntfs-3g   defaults,nosuid,nodev,locale=en_US.UTF-8   0   0
LABEL=SG-18-4T   /media/ronald/SG-18-4T   ext4   defaults,nosuid,nodev   0   0
LABEL=BU-19-4T   /media/ronald/BU-19-4T   ntfs-3g   defaults,nosuid,nodev,locale=en_US.UTF-8   0   0

These three lines show in a sequence different disks (different brand name of disks = Seagate/Buffalo), sequence of disk (17~19) and capacity of disk (4T) and file system

With that in place the disks are mounted always the same way.

[Takeshi_Kovacs]

hiya folks, it's me again with another random technical question...

So, I've got myself 4T spread across 4 disks, and I've plotted and optimized and such (3.2T worth of nonces), and I'm mining away happily on cryptomining.farm using Uray's miner r4.  In the past, I had no problems getting dcct's plotter and optimizer to work, but with a few different pools, I was unable to get the dcct miner to work, thus why I found myself using Uray's miner.  Uray's miner is working ok, BUT, I've organized my disks into 50G plotfiles (16 files per disk), and when it gets a block, it seems to try to read all plot files across all disks at once, basically blowing up all disks at once, and making the machine put up massive load averages, while just basically waiting for IO.  (I was using an old thin client, turned low power "server" to mine, but to try to help this, I'm now mining on 8 threads/4G RAM dedicated to the miner, and it's still melting whatever box I mine on)

So, I guess my question is there any way to configure Uray's miner read the plots sequentially, or one disk at a time?  Or, do any of the other cpu miners out there do that?  It would seem I could get the same sort of speed per round, without beating the crap out of my machine that way...

I can't be the first to observe and/or request this, right?

Thanks.

The dcct miner as it stands does not work on the dev2 pool.

If you want a version of that miner that works on the dev v2 pool, I can help.

I modded it for my own use last year and used it for a while until I went solo. I asked dcct if he wanted to take my mods but got no reply and when I posted to ask if anyone wanted to test it, there was no interest.

But I do still have it laying around somewhere if you, or anyone else want.

I gave a copy to a friend and he has been using it for months without problems so I guess that it works OK.

[yeponlyone]

I like the company idea, but wouldn't we end up in pretty close to the same situation with the need for investors?

You need to convince investors that the company will make money down the line.
If the investors can buy BTC and not really have to fiddle with BURST, you have a somewhat larger audience, however their asset holdings should probably be registered in the BURST chain,so an investor would need help to have a wallet established with a secure password that has not been leaked. ( or a thief could move the assets off the account )

The great thing about the company is that the company is seperate from the core dev group. The core dev group can still make sure BURST is stable and true to whatever the larger group of users want. The company owners can speed up development of services and whatever BURST stuff is needed to establish such services, and make money off the products. Company could also run mining pools or websites related to burst, if the company thinks such websites could be profitable, or somehow raise the burst price enough to warrant development.

Suppose the company developed file storage in burstcoin.  The dev team would then still have the final say about if and when the file storage stuff is relased in burstcoin, but the feature is done, and the company will be first in line to profit off such a feature, as the company has the best tech insight, and have had time to develop ways to profit from the new infrastructure. The company might release a file storage mining pool close to day 1, and offer to lease the source for the pool to other people who want to own a file storage pool. revenues from FS pool and lease to others could then over time generate a nice ROI of the company money spent on software development.

Suppose the company developed coin anonymization support in BURST.  as soon as the new version was released, the company would have a website ready and be marketing it to users. Company would have a head start with the stuff it sponsors, as it has the knowledge and of course it might have had influence on the feature set so that the capabilities match well with company needs.

With a good story, and with marketing both inside and outside burst community, you might have an easy sell.

Basically, funding a company that will drive development of services and products that utilize BURST, a company dedicated to grow and make money by being first mover in new technologies. Opportunity for shareholders to get in at a low price, in a company that could be a major player in select areas like encrypted anonymouse file storage, areas like crypto finance, areas like automated transactions - bleeding edge stuff..

The more I think about it, the more I like it, and I would very much enjoy setting up and running something like this. There would be need for initial investment for promotion and I could do as much twitter and forum promotion in various areas of this forum to promote it.

Do you think this would have to be another separate company completely? Or could I wrap it together as part of my existing company something like I did with ByteEnterprises?

The whole thing I keep thinking about though, is the idea that we'd still be in need of investors, however, it shouldn't be THAT hard to find people who'd be more willing to invest in a company than a particular coin, even if that company is working almost solely for that particular coin's technology. The company wouldn't necessarily be fully limited to that coin either. If there WERE a clone that came out, said company would be most likely interested in that as well, as the technology would be available there as well.

very interesting. I wonder if this could be something I could make happen.

One thing though, is that the stuff we're working with is open source, so what would keep others from just ripping off the ideas we paid to have developed and doing it themselves? Not quite the same as the company you formed for the idea you mentioned.

Looking for external funding, a version of this has been the search for seed money from angel investors and early stages venture capital firms and establish contact over Twitter that Karl Perkins and I have been working on for a while, and I informed you, crowe, about. Recently something new started to happened: "they" have started to find us too, and not just the other around.

But as I said: investors want something. Seed money does necessarily need to be in the form of money, as when they leave the process, the company is really small (and luckily replaced by more established VCs), but they want some in return for that initial investment: shares, representatives, advisers, etc.

This area of funding attract a great deal of crowdfunding companies too.

You can have a look at my Karl resp. my Twitter (we have also worked with anonymous accounts which I wont name here):

https://twitter.com/YepOnlyOne

https://twitter.com/karl_perkin

Click on Followers and Following.