Author

Topic: [ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000 - page 926. (Read 2170895 times)

sr. member
Activity: 256
Merit: 250
anyone tried mining BURST on cloud yet??


not on a public cloud which can be setuped to automatically clone plotting/mining instances but on my private cloud manually ;-)

on centos you only install the core system from the setup and run this:
yum groupinstall "Development Tools"
yum install java* screen git
mkdir burst
cd burst
git clone https://github.com/BurstProject/burstcoin
git clone https://github.com/BurstProject/pocminer

cd burstcoin
chmod +x *.sh
./compile.sh
screen -dmS wallet ./run.sh
cd..

cd pocminer
chmod +x *.sh
./compile.sh
screen -dmS mine ./run_mine.sh
upload or generate your passphrase.txt
screen -dmS plot ./run_generate.sh address start count stagger threads
 
full member
Activity: 196
Merit: 100
I'm on the moon
i have i5 cpu,16gb ram and free 2TB HDD now ı'm using this conf. is it true?Why ask u because ı started to mine 24 hours ago and ı find nothing what can ı do?
C:\Windows\System32\java.exe -Xmx4000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate "ID" 1 8191 400000 12
Anybody help me what's wrong


Do you have already generated the plot file?
pot file what is this???
how can ı create pot file???
hero member
Activity: 588
Merit: 500
Guys, i have a question. If I accidentally closed the CMD when it's plotting, can i continue the plots? How would I know where it stopped?

burstcoin.info/faq.php

Good link, thx. But it doesn't mention about continuing the plots and how to know where it stopped. Guys, any help on this?

Check the file size, and, just to be safe, start the new plots way above the old ones, it doesn't actually matter.
hero member
Activity: 868
Merit: 1000
for most people their better off buying coin. Just set a low buy order and u chance of return is far greater than mining and much faster. Buying coin can get ROI in hours or days. Mining will take weeks to months.
sr. member
Activity: 334
Merit: 250
🌟 æternity🌟 blockchain🌟
Guys, i have a question. If I accidentally closed the CMD when it's plotting, can i continue the plots? How would I know where it stopped?

burstcoin.info/faq.php

Good link, thx. But it doesn't mention about continuing the plots and how to know where it stopped. Guys, any help on this?
full member
Activity: 494
Merit: 100
Thank. Btw, I'm have R9 290 GPU to test with.

Can't get it work and What is reco for R9 Series Card ?

Hi everyone,

After many hours of setup I finally made it. I have a 1Tb generation in progress and 3x100Gb already finished.
I would like to test the V2 pool but I haven't any BURST for now. Could someone send me 1 BURST to test it please ? Here is my address : BURST-YA29-QCEW-QXC3-BKXDL.

Regarding the plot generation, I found an OpenCL implementation of Shabal (https://github.com/aznboy84/X15GPU/blob/master/kernel/shabal.cl) that could be used to make a GPU version of the generator. I will try to work on it when I have some free time.

Regards

Hi everyone,

As promised I have been working on a GPU plot generator on the last few days. I made a little program built on top of OpenCL, and it seems to work pretty well in CPU mode. Unfortunately, I can't test the GPU mode as it requires a very powerfull graphic card (with at least 46kB private memory per compute unit, because the algorithm needs at least 4096*64 static bytes to store an entire plot).

Here is a preview you can test for now :
gpuPlotGenerator-src-1.0.0.7z : https://mega.co.nz/#!bcF2yKKL!3Ud86GaibgvwBehoxkbO4UNdiBgsaixRx7ksHrgNbDI
gpuPlotGenerator-bin-win-x86-1.0.0.7z : https://mega.co.nz/#!HJsziTCK!UmAMoEHQ3z34R4RsXoIkYo9rYd4LnFtO_pw-R4KObJs

I will build another release in the end of the day with some minor improvements (threads per compute unit selection, output of OpenCL error codes, improvement of the Makefile to generate the distribution directly).
I will also try to figure out another mean to dispatch the work between the GPU threads to reduce the amount of private memory needed by the program.

For the windows people, you can use the binary version directly.
For the linux people, just download the source archive, make sure to modify the OpenCL library and lib path in the makefile (and maybe the executable name), and build the project via "make". To run the program, you need the "kernel" and the "plots" directories beside the executable.

The executable usage is : ./gpuPlotGenerator

The parameters are the same as the original plot generator, without the threads number.

If you find bugs or if you want some new features, let me now.

If you want to support me, here are my Bitcoin and Burst addresses :
Bitcoin: 138gMBhCrNkbaiTCmUhP9HLU9xwn5QKZgD
Burst: BURST-YA29-QCEW-QXC3-BKXDL

Regards

Unfortunately, I can't test the GPU mode as it requires a very powerfull graphic card (with at least 46kB private memory per compute unit, because the algorithm needs at least 4096*64 static bytes to store an entire plot).
It's nice to see someone else working on this, since I seem to have failed in it.

Private memory is actually part of global on AMD cards, so storing it in private isn't any better than just using global for everything; it's local that needs to aimed for for the massive speedup. No AMD cards have more than 64KB local per workgroup, which makes storing it all in local impossible however.

I haven't tried your implementation yet, but on my own first attempt, I also used global on everything also, and the result was faster than the java plotter, but slower than dcct's c plotter. My 2nd attempt used a 32KB local buffer I rotated through for storing the currently being hashed stuff, however I couldn't figure out how to get it copied also to global fast enough, and the local -> global copy killed the performance.

You might be interested in those kernels here: https://bitcointalksearch.org/topic/m.8695829

Thanks, I will look at your kernels to see if I can find a better solution.

Here is the new version. I reduced the amount of memory used from 40KB to about 1KB per unit. The only drawback is that it requires twice the global memory as before. I will search a mean to reduce this overhead later.
In CPU mode, it all goes pretty well (when no graphic card is detected).
The GPU mode is still kind of buggy on my graphic card (an old GeForce 9300M GS), don't know the exact reason yet. Sometimes it works, sometimes not. I will try to fix this issue tomorrow.

Here are the files :
gpuPlotGenerator-src-1.1.0.7z : https://mega.co.nz/#!iYFWAL5B!BvtmRQ5qGq4gGwjDglFNtDtNIX4LDaUvATBtClBdTlQ
gpuPlotGenerator-bin-win-x86-1.1.0.7z : https://mega.co.nz/#!aBVGBBQD!tBsRtb8VrHR12_anrFTrl41U0fPQu_OqFnxyi5nCyBY

For the linux users, the Makefile has a new target named "dist" that builds and copy/paste all the necessary files to the "bin" directory.

The executable usage is : ./gpuPlotGenerator

: the path to the plots directory
: number of parrallel threads for each work group

Hi,

I am aware of the current bug and I will work on it today.
For the parameter, use a multiple of 64, the typical value is 256 for most of the graphic cards.
full member
Activity: 196
Merit: 100
I'm on the moon
i have i5 cpu,16gb ram and free 2TB HDD now ı'm using this conf. is it true?Why ask u because ı started to mine 24 hours ago and ı find nothing what can ı do?
C:\Windows\System32\java.exe -Xmx4000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate "ID" 1 8191 400000 12
Anybody help me what's wrong


Do you have already generated the plot file?
pot file what is this???
hero member
Activity: 518
Merit: 500
Can't get it work and What is reco for R9 Series Card ?

Hi everyone,

After many hours of setup I finally made it. I have a 1Tb generation in progress and 3x100Gb already finished.
I would like to test the V2 pool but I haven't any BURST for now. Could someone send me 1 BURST to test it please ? Here is my address : BURST-YA29-QCEW-QXC3-BKXDL.

Regarding the plot generation, I found an OpenCL implementation of Shabal (https://github.com/aznboy84/X15GPU/blob/master/kernel/shabal.cl) that could be used to make a GPU version of the generator. I will try to work on it when I have some free time.

Regards

Hi everyone,

As promised I have been working on a GPU plot generator on the last few days. I made a little program built on top of OpenCL, and it seems to work pretty well in CPU mode. Unfortunately, I can't test the GPU mode as it requires a very powerfull graphic card (with at least 46kB private memory per compute unit, because the algorithm needs at least 4096*64 static bytes to store an entire plot).

Here is a preview you can test for now :
gpuPlotGenerator-src-1.0.0.7z : https://mega.co.nz/#!bcF2yKKL!3Ud86GaibgvwBehoxkbO4UNdiBgsaixRx7ksHrgNbDI
gpuPlotGenerator-bin-win-x86-1.0.0.7z : https://mega.co.nz/#!HJsziTCK!UmAMoEHQ3z34R4RsXoIkYo9rYd4LnFtO_pw-R4KObJs

I will build another release in the end of the day with some minor improvements (threads per compute unit selection, output of OpenCL error codes, improvement of the Makefile to generate the distribution directly).
I will also try to figure out another mean to dispatch the work between the GPU threads to reduce the amount of private memory needed by the program.

For the windows people, you can use the binary version directly.
For the linux people, just download the source archive, make sure to modify the OpenCL library and lib path in the makefile (and maybe the executable name), and build the project via "make". To run the program, you need the "kernel" and the "plots" directories beside the executable.

The executable usage is : ./gpuPlotGenerator

The parameters are the same as the original plot generator, without the threads number.

If you find bugs or if you want some new features, let me now.

If you want to support me, here are my Bitcoin and Burst addresses :
Bitcoin: 138gMBhCrNkbaiTCmUhP9HLU9xwn5QKZgD
Burst: BURST-YA29-QCEW-QXC3-BKXDL

Regards

Unfortunately, I can't test the GPU mode as it requires a very powerfull graphic card (with at least 46kB private memory per compute unit, because the algorithm needs at least 4096*64 static bytes to store an entire plot).
It's nice to see someone else working on this, since I seem to have failed in it.

Private memory is actually part of global on AMD cards, so storing it in private isn't any better than just using global for everything; it's local that needs to aimed for for the massive speedup. No AMD cards have more than 64KB local per workgroup, which makes storing it all in local impossible however.

I haven't tried your implementation yet, but on my own first attempt, I also used global on everything also, and the result was faster than the java plotter, but slower than dcct's c plotter. My 2nd attempt used a 32KB local buffer I rotated through for storing the currently being hashed stuff, however I couldn't figure out how to get it copied also to global fast enough, and the local -> global copy killed the performance.

You might be interested in those kernels here: https://bitcointalksearch.org/topic/m.8695829

Thanks, I will look at your kernels to see if I can find a better solution.

Here is the new version. I reduced the amount of memory used from 40KB to about 1KB per unit. The only drawback is that it requires twice the global memory as before. I will search a mean to reduce this overhead later.
In CPU mode, it all goes pretty well (when no graphic card is detected).
The GPU mode is still kind of buggy on my graphic card (an old GeForce 9300M GS), don't know the exact reason yet. Sometimes it works, sometimes not. I will try to fix this issue tomorrow.

Here are the files :
gpuPlotGenerator-src-1.1.0.7z : https://mega.co.nz/#!iYFWAL5B!BvtmRQ5qGq4gGwjDglFNtDtNIX4LDaUvATBtClBdTlQ
gpuPlotGenerator-bin-win-x86-1.1.0.7z : https://mega.co.nz/#!aBVGBBQD!tBsRtb8VrHR12_anrFTrl41U0fPQu_OqFnxyi5nCyBY

For the linux users, the Makefile has a new target named "dist" that builds and copy/paste all the necessary files to the "bin" directory.

The executable usage is : ./gpuPlotGenerator

: the path to the plots directory
: number of parrallel threads for each work group

Hi,

I am aware of the current bug and I will work on it today.
For the parameter, use a multiple of 64, the typical value is 256 for most of the graphic cards.

So, the parameter is not needed for Windows exe? Is the
parameter the numerical address created from the passphrase? How does this gpu plotter perform vs the cpu plotter? Are the plots error free or is there a margin of error compared to the cpu plotted ones?

Update: Didn't read it properly about the thread parameter, understand it's required for Windows and Linux. Why is the multiples 64 (same as the scoop size) and typical value 256 (same as the plot size) for gpu's?
sr. member
Activity: 256
Merit: 250
Is there any way to generate plot files locally using an EC2 instance?

For example, I have a local 4TB storage but I want to plot in the cloud via streaming the files. Does something like this exist? I DON'T want to store the files in EBS since that will cost me a ton. Or is downloading from EBS and then wiping the only way? Does S3 charge for the whole month on the spot or is it hourly/daily/averaged?
you can connect the ec2 instance to your local network using generic network approaches.
not sure how much traffic costs but if you have a 100mbit internet connection expect to get 10mb/s to fill up your 4 tb drive. it would take about 5 days to transfer.
hero member
Activity: 1036
Merit: 531
This is normal that deadline fluctuate a lot and not really regular in size?

yeah, it's like mining in solo

Ok so i don't have to worry if i have sometimes 4numbers and sometimes 8

Do you solve your memory problem?

no lol, but it's releated to the paging file of the kernel memory, check your and tell me

anyway i'm installing linux fuck that shit lol

D'ont know if that helps, but that's what i have for mining 9tb, i'm not ploting on the same computer

hero member
Activity: 588
Merit: 500
i have i5 cpu,16gb ram and free 2TB HDD now ı'm using this conf. is it true?Why ask u because ı started to mine 24 hours ago and ı find nothing what can ı do?
C:\Windows\System32\java.exe -Xmx4000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate "ID" 1 8191 400000 12
Anybody help me what's wrong

Yes, swap over the 40000 and the 8191, they are in the wrong order, also, i suggest you increase your xm value to like 12000
legendary
Activity: 3766
Merit: 1742
Join the world-leading crypto sportsbook NOW!
i have i5 cpu,16gb ram and free 2TB HDD now ı'm using this conf. is it true?Why ask u because ı started to mine 24 hours ago and ı find nothing what can ı do?
C:\Windows\System32\java.exe -Xmx4000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate "ID" 1 8191 400000 12
Anybody help me what's wrong


Do you have already generated the plot file?
member
Activity: 60
Merit: 10
Hi everyone,

After many hours of setup I finally made it. I have a 1Tb generation in progress and 3x100Gb already finished.
I would like to test the V2 pool but I haven't any BURST for now. Could someone send me 1 BURST to test it please ? Here is my address : BURST-YA29-QCEW-QXC3-BKXDL.

Regarding the plot generation, I found an OpenCL implementation of Shabal (https://github.com/aznboy84/X15GPU/blob/master/kernel/shabal.cl) that could be used to make a GPU version of the generator. I will try to work on it when I have some free time.

Regards

Hi everyone,

As promised I have been working on a GPU plot generator on the last few days. I made a little program built on top of OpenCL, and it seems to work pretty well in CPU mode. Unfortunately, I can't test the GPU mode as it requires a very powerfull graphic card (with at least 46kB private memory per compute unit, because the algorithm needs at least 4096*64 static bytes to store an entire plot).

Here is a preview you can test for now :
gpuPlotGenerator-src-1.0.0.7z : https://mega.co.nz/#!bcF2yKKL!3Ud86GaibgvwBehoxkbO4UNdiBgsaixRx7ksHrgNbDI
gpuPlotGenerator-bin-win-x86-1.0.0.7z : https://mega.co.nz/#!HJsziTCK!UmAMoEHQ3z34R4RsXoIkYo9rYd4LnFtO_pw-R4KObJs

I will build another release in the end of the day with some minor improvements (threads per compute unit selection, output of OpenCL error codes, improvement of the Makefile to generate the distribution directly).
I will also try to figure out another mean to dispatch the work between the GPU threads to reduce the amount of private memory needed by the program.

For the windows people, you can use the binary version directly.
For the linux people, just download the source archive, make sure to modify the OpenCL library and lib path in the makefile (and maybe the executable name), and build the project via "make". To run the program, you need the "kernel" and the "plots" directories beside the executable.

The executable usage is : ./gpuPlotGenerator

The parameters are the same as the original plot generator, without the threads number.

If you find bugs or if you want some new features, let me now.

If you want to support me, here are my Bitcoin and Burst addresses :
Bitcoin: 138gMBhCrNkbaiTCmUhP9HLU9xwn5QKZgD
Burst: BURST-YA29-QCEW-QXC3-BKXDL

Regards

Unfortunately, I can't test the GPU mode as it requires a very powerfull graphic card (with at least 46kB private memory per compute unit, because the algorithm needs at least 4096*64 static bytes to store an entire plot).
It's nice to see someone else working on this, since I seem to have failed in it.

Private memory is actually part of global on AMD cards, so storing it in private isn't any better than just using global for everything; it's local that needs to aimed for for the massive speedup. No AMD cards have more than 64KB local per workgroup, which makes storing it all in local impossible however.

I haven't tried your implementation yet, but on my own first attempt, I also used global on everything also, and the result was faster than the java plotter, but slower than dcct's c plotter. My 2nd attempt used a 32KB local buffer I rotated through for storing the currently being hashed stuff, however I couldn't figure out how to get it copied also to global fast enough, and the local -> global copy killed the performance.

You might be interested in those kernels here: https://bitcointalksearch.org/topic/m.8695829

Thanks, I will look at your kernels to see if I can find a better solution.

Here is the new version. I reduced the amount of memory used from 40KB to about 1KB per unit. The only drawback is that it requires twice the global memory as before. I will search a mean to reduce this overhead later.
In CPU mode, it all goes pretty well (when no graphic card is detected).
The GPU mode is still kind of buggy on my graphic card (an old GeForce 9300M GS), don't know the exact reason yet. Sometimes it works, sometimes not. I will try to fix this issue tomorrow.

Here are the files :
gpuPlotGenerator-src-1.1.0.7z : https://mega.co.nz/#!iYFWAL5B!BvtmRQ5qGq4gGwjDglFNtDtNIX4LDaUvATBtClBdTlQ
gpuPlotGenerator-bin-win-x86-1.1.0.7z : https://mega.co.nz/#!aBVGBBQD!tBsRtb8VrHR12_anrFTrl41U0fPQu_OqFnxyi5nCyBY

For the linux users, the Makefile has a new target named "dist" that builds and copy/paste all the necessary files to the "bin" directory.

The executable usage is : ./gpuPlotGenerator

: the path to the plots directory
: number of parrallel threads for each work group

So the usage would be like this: "D:/gpuPlotGenerator 0  819200 4096 "

Is that format correct? Is the thread count need for gpu plotting(Point out in bold)? What's the nonce/minute rate?

Hi,

This is still a buggy early stage version. I post it here to have feedback from people who owns more powerfull graphic cards (the behaviour may vary from one card to another).
But yes, the final usage would be the one you mentioned. The threads parameter is the number of threads used in the local work group. In GPU mode, the value should be a multiple a 64, 256 is the typical value for most of the cards.
full member
Activity: 196
Merit: 100
I'm on the moon
i have i5 cpu,16gb ram and free 2TB HDD now ı'm using this conf. is it true?Why ask u because ı started to mine 24 hours ago and ı find nothing what can ı do?
C:\Windows\System32\java.exe -Xmx4000m -cp pocminer.jar;lib/*;lib/akka/*;lib/jetty/* pocminer.POCMiner generate "ID" 1 8191 400000 12
Anybody help me what's wrong
sr. member
Activity: 376
Merit: 250
anyone tried mining BURST on cloud yet??

sr. member
Activity: 355
Merit: 250
Can someone explain how to mine in pool: http://burst-pool.cryptoport.io/

I did everything frome here: http://burst-pool.cryptoport.io/howto.html
I download java pool miner from pool website
Miner is working, no errors

But i dont see any shares from my address in pool statistics.
Any advice ?
member
Activity: 60
Merit: 10
Can't get it work and What is reco for R9 Series Card ?

Hi everyone,

After many hours of setup I finally made it. I have a 1Tb generation in progress and 3x100Gb already finished.
I would like to test the V2 pool but I haven't any BURST for now. Could someone send me 1 BURST to test it please ? Here is my address : BURST-YA29-QCEW-QXC3-BKXDL.

Regarding the plot generation, I found an OpenCL implementation of Shabal (https://github.com/aznboy84/X15GPU/blob/master/kernel/shabal.cl) that could be used to make a GPU version of the generator. I will try to work on it when I have some free time.

Regards

Hi everyone,

As promised I have been working on a GPU plot generator on the last few days. I made a little program built on top of OpenCL, and it seems to work pretty well in CPU mode. Unfortunately, I can't test the GPU mode as it requires a very powerfull graphic card (with at least 46kB private memory per compute unit, because the algorithm needs at least 4096*64 static bytes to store an entire plot).

Here is a preview you can test for now :
gpuPlotGenerator-src-1.0.0.7z : https://mega.co.nz/#!bcF2yKKL!3Ud86GaibgvwBehoxkbO4UNdiBgsaixRx7ksHrgNbDI
gpuPlotGenerator-bin-win-x86-1.0.0.7z : https://mega.co.nz/#!HJsziTCK!UmAMoEHQ3z34R4RsXoIkYo9rYd4LnFtO_pw-R4KObJs

I will build another release in the end of the day with some minor improvements (threads per compute unit selection, output of OpenCL error codes, improvement of the Makefile to generate the distribution directly).
I will also try to figure out another mean to dispatch the work between the GPU threads to reduce the amount of private memory needed by the program.

For the windows people, you can use the binary version directly.
For the linux people, just download the source archive, make sure to modify the OpenCL library and lib path in the makefile (and maybe the executable name), and build the project via "make". To run the program, you need the "kernel" and the "plots" directories beside the executable.

The executable usage is : ./gpuPlotGenerator

The parameters are the same as the original plot generator, without the threads number.

If you find bugs or if you want some new features, let me now.

If you want to support me, here are my Bitcoin and Burst addresses :
Bitcoin: 138gMBhCrNkbaiTCmUhP9HLU9xwn5QKZgD
Burst: BURST-YA29-QCEW-QXC3-BKXDL

Regards

Unfortunately, I can't test the GPU mode as it requires a very powerfull graphic card (with at least 46kB private memory per compute unit, because the algorithm needs at least 4096*64 static bytes to store an entire plot).
It's nice to see someone else working on this, since I seem to have failed in it.

Private memory is actually part of global on AMD cards, so storing it in private isn't any better than just using global for everything; it's local that needs to aimed for for the massive speedup. No AMD cards have more than 64KB local per workgroup, which makes storing it all in local impossible however.

I haven't tried your implementation yet, but on my own first attempt, I also used global on everything also, and the result was faster than the java plotter, but slower than dcct's c plotter. My 2nd attempt used a 32KB local buffer I rotated through for storing the currently being hashed stuff, however I couldn't figure out how to get it copied also to global fast enough, and the local -> global copy killed the performance.

You might be interested in those kernels here: https://bitcointalksearch.org/topic/m.8695829

Thanks, I will look at your kernels to see if I can find a better solution.

Here is the new version. I reduced the amount of memory used from 40KB to about 1KB per unit. The only drawback is that it requires twice the global memory as before. I will search a mean to reduce this overhead later.
In CPU mode, it all goes pretty well (when no graphic card is detected).
The GPU mode is still kind of buggy on my graphic card (an old GeForce 9300M GS), don't know the exact reason yet. Sometimes it works, sometimes not. I will try to fix this issue tomorrow.

Here are the files :
gpuPlotGenerator-src-1.1.0.7z : https://mega.co.nz/#!iYFWAL5B!BvtmRQ5qGq4gGwjDglFNtDtNIX4LDaUvATBtClBdTlQ
gpuPlotGenerator-bin-win-x86-1.1.0.7z : https://mega.co.nz/#!aBVGBBQD!tBsRtb8VrHR12_anrFTrl41U0fPQu_OqFnxyi5nCyBY

For the linux users, the Makefile has a new target named "dist" that builds and copy/paste all the necessary files to the "bin" directory.

The executable usage is : ./gpuPlotGenerator

: the path to the plots directory
: number of parrallel threads for each work group

Hi,

I am aware of the current bug and I will work on it today.
For the parameter, use a multiple of 64, the typical value is 256 for most of the graphic cards.
sr. member
Activity: 376
Merit: 250
I am having difficulty following the miner tutorial posted in the announcement thread, anyone help me with this?

I'll give a VPS with 2 TB HDD as a compensation for your lost time.

What's the problem?

messaged you, check your PM.
thanks for replying.
hero member
Activity: 588
Merit: 500
I am having difficulty following the miner tutorial posted in the announcement thread, anyone help me with this?

I'll give a VPS with 2 TB HDD as a compensation for your lost time.

What's the problem?
legendary
Activity: 1932
Merit: 1042
https://locktrip.com/?refId=40964
question fo dev team

in the last few days volume and interest on burst coin are falling.

what are the future plans for the development of the coin?
Do you have a project plan?
Can you tell us what you're working on?
Give us some information so those who argue burst, can duffuse information about money and keep interest alive!

thanks so much
Jump to: