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

[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.

[duncan_idaho]

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.

Fully agree with You.

I am against to change total supply and against to change reward per block. We don't need inflation. Ivestors will not trust in coin with this kind of changes. If you want add new things then ok but don't touch core features.

[newuser01]

I haven't posted here for a few months now but what is this talk about taking block reward to devfund? this has to be a joke right? there is no way thats gonna work.

Also raising the block reward won't attract new miners. It will only turn on the cloud-mining that was shutdown when burst hit ~30-40 satoshi, now it's not worth mining so they shut it down. If you want an even lower price of burstcoin then yes increase the block reward because it will cause more dumping - because then cloudmining will be profitable again.

edit: grammar

[tonycamp]

burst coin its like no much profitable but fun to mine i dont see as a 10 dollars month income but as a block time to serch and some rewards into pools i like my 5TB to mine just for fun and what i dont like its the 30 satoshis now prefered like 70 to 80 to 200 of course but if not happens well i might keep mining still

[bobafett]

I haven't posted here for a few months now but what is this talk about taking block reward to devfund? this has to be a joke right? there is no way thats gonna work.

Also raising the block reward won't attract new miners. It will only turn on the cloud-mining that was shutdown when burst hit ~30-40 satoshi, now it's not worth mining so they shut it down. If you want an even lower price of burstcoin then yes increase the block reward because it will cause more dumping - because now cloudmining is profitable again.

i dont know anybody who has a useful working cloud mining szenario. exept perhaps bin.

[italianMiner72]

I haven't posted here for a few months now but what is this talk about taking block reward to devfund? this has to be a joke right? there is no way thats gonna work.

Also raising the block reward won't attract new miners. It will only turn on the cloud-mining that was shutdown when burst hit ~30-40 satoshi, now it's not worth mining so they shut it down. If you want an even lower price of burstcoin then yes increase the block reward because it will cause more dumping - because now cloudmining is profitable again.

+1

hi guys..
i don't understand...
there is a new block reward algo?
or dev are just talking about the possibility to change it?

[bobafett]

there is just a discussion about that.

our dev is gone and not reachable for months now.

the only one atm perhaps who could at least release a new version with the from himself proposed changes is bitladen, but it is not clear, if the community will follow.

so atm nothing will change until bin concretizes his plans. hes talking for month now about this changes, but also nothing happens....

[italianMiner72]

there is just a discussion about that.

our dev is gone and not reachable for months now.

the only one atm perhaps who could at least release a new version with the from himself proposed changes is bitladen, but it is not clear, if the community will follow.

so atm nothing will change until bin concretize his plans. hes talking for month now about this changes, but also nothing happens....

i really don't understand why the dev is gone...
i see his last post was on: June 16, 2015, 02:35:26 AM.

a long time ago!!!

but there is a official reason for his leave?