Niedrige Einstiegskosten und ein umweltfreundlicher Algorithmus – nutzen Sie Ihren freien Festplattenspeicher!
Der PoC-Algorithmus (Proof of Capacity) sichert das Netzwerk durch Festplattenspeicher, der nur gelesen werden muss, wenn ein Block erstellt wird. Das bedeutet, dass fast kein Strom verbraucht wird, keine zusätzliche Hardware benötigt wird und im Gegensatz zu den starken CPUs, GPUs oder ASICs, die in den PoW-Frameworks benötigt werden, sehr wenig Lärm und Abwärme entsteht. Mit Burst treffen Sie die Entscheidung für einen umweltfreundlichen und zukunftsweisenden Konsensalgorithmus.
Keine zusätzliche Hardware erforderlich
Für das Mining von Burst kann jeder PC oder jedes Handy (egal wie alt) verwendet werden. Das Einzige, was Sie benötigen, ist Festplattenspeicher, um die Plotdateien für das kontinuierliche Lesen bereit zu erstellen. Burst gibt mit seinem PoC-Algorithmus damit jedem die Möglichkeit ohne große Einstiegshürden am Mining-Prozess teilzunehmen, sei es als Solo-Miner oder über ein Mining-Pool.
3 Schritte zum Start
Schritt 1 – Plotting
Miner generieren vorab Datenblöcke (Plots), die alle Berechnungen enthalten, die zum Erstellen von Blöcken notwendig sind.
Schritt 2 – Reward assignment
Miner treten einem Pool bei, indem sie ihn als Begünstigten definieren. Der Pool erhält die Block-Belohnung, falls er einen Block erzeugt.
Schritt 3 – Mining
Die Mining-Software liest automatisch die Dateien durch und sucht nach einer kürzesten Frist (DL) und sendet sie an eine Wallet, welche versucht den Block mit dieser Frist zu erzeugen.
Der Begriff Plotten ist ein Name für die Bereitstellung von Speicherplatz für Berechnungen im Burstcoin-Netzwerk. Ein Plot ist eine Datei mit vorberechneten Hashes, die verwendet werden kann, um Blöcke für Burstcoin Blockchain zu erstellen. Die Plot-Files werden später von der Mining-Software genutzt und können als die Hash-Rate des Miners angesehen werden.
Before we dive deep into how plotting works we need to get familiar with all different terms used in the procedure.
Shabal is the name of the crypto/hash function used in Burstcoin. Shabal is a rather heavy and slow crypto in relation to many other like i.e. SHA256. Because of this it makes it a good crypto for Proof of capacity coins like Burstcoin. This is because we store the precomputed hashes while it is still fast enough to do smaller live verifications. Burst uses the 256bit version of Shabal also known as Shabal256.
Hash / Digest
A hash or digest in this context is a 32Byte (256bit) long result of the Shabal256 Crypto.
When generating a plot file, you generate something that is called nonces. Each nonce contains 256Kilobyte of data that can be used by miners to calculate Deadlines. Each nonce will have its own individual number. This number can range between 0-18446744073709551615. the number is also used as a seed when creating the nonce. Because of this each nonce has its own unique set of data. One plot file can contain many nonces.
Each nonce is sorted into 4096 different places of data. These places are called scoop numbers. Each scoop contains 64byte of data which holds 2 hashes. Each of these hashes are xored with a final hash (we get to final hash in generating a nonce chapter).
When you create your plot file it will be bound to a specific Burst account. The numeric account ID is used when you create your nonces. Because of this all miners have different plot files even if they use the same nonce numbers.
The first step in creating a nonce is to make the first seed. The seed is a 16byte long value containing the account id that we will be generating a nonce for and the nonce number. When this is done we start to feed the Shabal256 function to get our first hash.
We have produced the first hash. This is the last hash in the nonce. Hash #8191. Now we take this produced hash (#8191) and pre-append it to the starting seed. The result will now be our new seed for the next round of shabal256 computation.
We now have produced two hashes. Hash #8191 and Hash #8190. This time we pre-append Hash 8190 to the last seed we used. The result will now be a new seed to feed Shabal256.
Once again, we have created a new hash. This procedure of pre-appending resulting hashes to a new seed will continue for all 8192 hashes we create for a nonce. After iteration 128 we have reached more than 4096 bytes in the seed. For all remaining iterations we will only read the last 4096 generated bytes.
Once we have created 8192 hashes we are now going to make a Final hash. This is done by using all 8192 hashes and the first 16bytes as seed.
The final hash will now be used to xor all other hashes individually.
We have now created our nonce and can store it in a plot file before we continue to the next nonce.
The POC2 nonce format is created the same way as when we create POC1 with a slight addition to the end of the process. To create a POC2 formatted nonce we need to shuffle the data around. If we divide the nonce in 2 halves we get a range with scoops 0-2047 and 2048-4095. Let’s call 0-2047 the low scoop range and 2048-4095 the high scoop range. To shuffle the data into correct place we take the second hash from a scoop in the low range and swap it with the second hash in its mirror scoop found in the high range. The mirror scoop is calculated like this:
MirrorScoop = 4095 – CurrentScoop
When we are mining we read from one or more plot files. The miner software will open a plot file and seek the scoop locations to read the scoops data. If the plot file is unoptimized the scoop locations will be on more than one place. In the following example the miner will be seeking and reading scoop #403.
This is not the most effective way since the miner will spend a lot of time to seek new locations on the storage device to be able to read the scoops. To prevent this, we can optimize plots or use plotter software that creates optimized plots from the beginning. Optimization is done by reordering the data in the plot file and grouping all data from the same scoop number together.
Basically, what we have done is to divide the plot file into 4096 portions where we split up all the nonces data based on scoop numbers. When the miner now wants to read Scoop 4096 it only seeks one time and read all data sequentially. This provides better performance.
A stagger is basically a group of nonces in a plot file. The groups in the plot file is written in an optimized way. A given stagger number tells you how many nonces there are in each group. To find out how many groups there are in a plot file you take the number of nonces and divide it with the stagger number. If the stagger number is equal to the number of nonces in the file, there is only one group and the plot file is completely optimized. If this is the case the miner will not care about the stagger. If for some reason your division ends up with decimals, your plot file can be assumed broken. Poc2 formatted plot files cannot have staggers. They are always written in an optimized way.
Since a plot file only contains raw data there is no headers in the files. All information needed for a user and miner is set in the filenames.
The formatting of the filename is as follows:
POC1 format: AccountID_StartingNonce_NrOfNonces_Stagger
POC2 format: AccountID_StartingNonce_NrOfNonces
Reward assignment is a transaction that notifies the network which account is to be credited for block rewards and transaction fees attributable to an individual miner’s account. It is a prerequisite for both solo and pool mining!
For solo burstcoin mining, the reward assignment transaction specifies the solo miner’s account. For burstcoin pool mining, the transaction specifies the mining pool operator’s account. In the context of pool mining, the reward assignment transaction delegates authority to the pool to uses the participating miner’s submitted deadlines and to sign newly forged blocks using the participating miner’s account. Note: forged blocks are always signed by the account belonging to the miner who submitted the deadline used to forge the block.
To perform the reward assignment transaction, consult the documentation for the specific wallet being used. The procedure generally follows this form: Select tools – enter reward recipient address in Reed-Solomon format – select “Set Reward Recipient”. Most wallets include a list of pool operations. Selecting from this list will generally configure the wallet automatically. Lists are updated frequently, but newer operations may not yet be included. In this case, information specific to the chosen pool operation will have to be added manually.
With most cryptocurrencies that are not based on Proof-of-Stake, there is a process called mining. This process is the foundation for a blockchain to grow and secure transactions within the network. Burstcoin is no different, except that you use precomputed hashes to find values that can be used to forge a block. To fully understand this document, you should read the document named technical information to create plot files. This document is intended to be an overview of the processes. It is technical information, but not deep enough to be used as a reference for a programmer since information regarding subjects like AT, subscriptions, and assets is missing.
Shabal / Sha256 / Curve25519
Shabal, Sha256 and Curve25519 are cryptographic hash functions used in this text. Shabal is the main one used by Burstcoin. Shabal is a rather heavy and slow cryptographic hash function in relation to many others like SHA256. Because of this, it makes it a good crypto for Proof-of-Capacity coins like Burstcoin. This is because we store the precomputed hashes, and it is still fast enough to do smaller live verifications. Burst uses the 256bit version of Shabal also known as Shabal256.
Hash / Digest
A hash, or digest in this context, is a result when computing data through a cryptographic hash function. If not said otherwise, the length of a hash is 32Bytes (256bit).
When mining, you read precomputed hashes from files stored on a storage device. These files are called plot files.
Within a plot file, there are one or more groups of data called nonces. One nonce contains 8192 hashes, and because of that, the nonces are 256KiB large. Each nonce has its own individual number. This 64bit number can range between 0-18446744073709551615 (264).
Each nonce is sorted into 4096 different places of data. These places are called scoop numbers. Each scoop contains 2 hashes. Each of these hashes are xored with a final hash.
When you create your plot file it will be bound to a specific Burst account. Because of this, all miners have different plot files.
When you mine and process your plot files, you will end up with resulting values called deadlines. The values represent the number of seconds that must elapse since last block was forged before you are allowed to forge a block. If no one else has forged a block within this time, you can forge a block and claim a block reward.
If you are lucky enough to forge a block, you will get Burstcoin as a reward. This is called a block reward. The block reward decreases 5% every 10800 blocks. This is roughly every 30 days since each block is supposed to be forged every 4 minutes (360 blocks a day).
Base target is calculated from the last 24 blocks. This value adjusts the difficulty for the miners. The lower the base target, the harder it is for a miner to find a low deadline. It gets adjusted in a way that Burstcoin can have an average of 4 minutes for each block.
Network Difficulty, or NetDiff in short, is a value that can be read as an estimate on the total amount of space in terabytes dedicated to mine Burstcoin. Since this is a value that changes with every block in relation to base target, it should be taken into an average of at least 360 values before considered to be somewhat accurate.
Every block forged gets an individual number. Every new block forged gets the previous block’s number + 1. This number is called block height, and can be used to identify a specific block.
When a block is forged, an account has found a nonce and a deadline. Block generator is the account used when forging a block. This is the account from which a deadline has been found when forging a block. This is always the real account even if a reward assignment has been set.
Generation signature is a based from the previous block generation signature and block generator. This value is then used by miners to forge a new block. Generation signature is 32bytes long.
Every block is signed by the generator who forges a block. This is done by taking most parts of the block and signing it with the block generator’s private key using both Sha256 and Curve25519. The result is a 64byte long hash.
Reward assignment is frequently used when pool mining. When changing your reward assignment, you tell the network that another account (the pool account) is acting in your place for 2 specific features. The first feature is that all block rewards that should be given to your account will now be given to the pool account instead. Secondly, for the pool to be able to utilize the deadlines found from your plot files, it is also granted the action to sign the newly forged blocks with the account belonging to the pool.
All references to wallet in this text can also be a pool depending on scenario.
All references to miner in this text is a software able to do a mining operation for Burstcoin.
The first thing that happens when you start mining, is that the miner talks to the wallet and asks for mining information. This information contains a new generation signature, base target, and the next block height. Before the wallet sends over this info, it creates the generation signature by taking the previous generation signature together with previous block generator and runs this though shabal256 to get the new hash. The miner will now take the new 32byte generation signature, and the 8byte block height, and put them together as a seed for Shabal256. The result will be a hash value called Generation hash.
Now, the miner will do a small mathematical operation on this hash to find out which scoop number to use when processing the plot files. This is done by taking the generation hash modulo 4096, as there are only that many scoops.
Next step for the miner is to read all the 64-byte long scoops from all nonces in all plot files. It will process them individually through shabal256 together with the new generation signature to get a new hash called target. This target is now divided with base target and the first 8bytes of the result is the value deadline.
To prevent so-called “nonce spamming” to the wallet, the miner usually checks if the current deadline found is lower than the lowest one it has found so far. Usually there is also a max value that can be set, as ridiculously large deadlines are of no use to anyone. After these checks, the miner submits information to the wallet. This information contains the numeric account ID bound to the plot file, and the nonce number that contains the scoop data used to generate the deadline. If you are solo mining the miner also sends over the passphrase for the account id used in plot files. If the password is not sent when solo mining, the wallet would be unable to forge blocks for that account. When pool mining, the passphrase for the pool account id is used.
The wallet has now received the information submitted by the miner, and will now create the nonce to be able to find and verify the deadline for itself. After this is done, the wallet will now check and see if an equal amount or more seconds has passed as defined by the deadline. If not, the wallet will wait until it has. If a valid forged block from another wallet is announced on the network before the deadline has passed, the wallet will discard the mining info submitted since it is no longer valid. If the miner submits new information, the wallet will create that nonce and check if the deadline value is lower than the previous value. If the new deadline is lower, the wallet will use that value instead. When the deadline is valid, the wallet will now start to forge a block.
There are two limits for a block. First, a block can contain max. 255 transactions. The second is that a block payload can have max. 44880bytes (43KiB). The wallet will start by getting all of the unconfirmed transactions it has received from users or from the network. It will try to fit as many of these transactions possible until it hits one of the limits, or until all transactions are processed. For each transaction the wallet reads, it will do checks. For example, if the transaction has a valid signature, if it has a correct timestamp, etc. The wallet will also sum up all of the added transactions amounts and fees. The block itself will only contain the Transaction ID of each transaction and one Sha256 hash of all the transactions included. Complete transactions are stored separately. Beside this, a block contains many different sets of values.
Block version number
The version number is basically telling the wallet what a block can contain and how it is contained. This number changes each time a block gets a new format.
List of Transaction ID
A List of all transaction IDs that are included in this block
This is the Sha256 hash of all the data in the payload of the block
A timestamp that will describe when the block was forged; derived from the birth of the blockchain. Birth date: 11 August 2014, Time: 02:00:00
Total amount of coins
This is the sum of all transactions in the block
Total amount of fees
This is the amount of fees that will be given to the block forger for generating this block.
The length of the payload
This is a number in bytes representing the length of the payload.
This is a public key for the account that forges the block.
The 32byte generation signature that was used to forge the block.
Previous block hash
A Sha256 hash of the contents from the previous block.
Previous block ID
This is the first 8 bytes in the previous block hash converted to a number.
Used to prevent Nothing at Stake problems during potential forks. Calculated: Previous Cumulative Difficulty + (18446744073709551616 / base target)
The base target used when forging this block
This block’s height value
This is the first 8 bytes in block’s hash converted to a number
The nonce number used to forge this block.
If an AT is added to this block, this is the payload bytes for that AT.
This is a 64byte hash generated with the forger’s private key and block contents. When this is done, it will be announced to the network. The wallet will connect to all peers and send the block over to them. The peer will receive the block and verify that all information is not spoofed.
Format : POC 1, POC 2
Engraver is a BURST plotter that natively generates optimized plot files.
It generates PoC2 files and is intended to work on any UNIX system with a sufficiently sane filesystem (able to pre-allocate space), but for now only Linux and MacOS have been tested.
Main Developer: PoC-Consortium
Download link: https://github.com/PoC-Consortium/engraver
Format : POC 1, POC 2
TurboPlotter 9000 is a CPU/GPU PoC 1 + PoC 2 plotter and plot integrity checker.
Main Developer: Blackpawn
Download link: https://blackpawn.com/tp/
Platform: Windows, Linux, MacOS
Format : POC1, POC 2
XplotterGui is a GUI version of Xplotter with SSD Cache, File Merging, and POC2 Conversion features.
Main Developer: JohnnyFFM
Download link: https://github.com/JohnnyFFM/XPlotterGui/releases/latest
Format : POC1, POC 2
XPlotter is the default plotter that comes with QBundle and provides CPU PoC 1 plotting with AVX support. This modified version supports PoC 2 plotting.
Main Developer: JohnnyFFM
Download link: https://github.com/JohnnyFFM/XPlotter/releases/tag/v.1.31
Satus : Stable, Outdated
Main Developer: bhamon
Download link: https://github.com/bhamon/gpuPlotGenerator/releases/tag/v4.2.2
Platform: Windows, Linux, MacOS
Scavenger is a burst miner written in Rust.
- SSE2, AVX, AVX2, AVX512F and NEON support
- OpenCL GPU support
Main Developer: PoC Consortium
Download link: https://github.com/PoC-Consortium/scavenger/releases
Platform: Windows, MacOS, Linux, Unix
(32 & 64 bit)
This softwate features:
- update with Collision free dual mining
- Tracking (and displaying) of possibly corrupted plot files
Main Developer: andzno1
Download link: https://github.com/andzno1/blagominer/releases
Burstcoin-jminer is a GPU assisted Proof of Capacity (PoC) Miner for Burst.
Main Developer: de-luxe
Download link: https://github.com/de-luxe/burstcoin-jminer/releases/tag/0.5.2-RELEASE
Platform: Windows, Linux, MacOS
CreepMiner is a client application for mining Burst on a pool or solo.
It supports CPU mining (SSE2/SSE4/AVX/AVX2) or GPU mining (OpenCL, CUDA).
Main Developer: Creepsky
Download link: https://github.com/Creepsky/creepMiner/releases
Platform: Windows, MacOS, Linux x86_64 or ARM7
A free of licence Burstcoin Poolsoftware created by BAT Developer Harry.
This pool-software can be downloaded from the burst-app-team-github.
The software is working with Java 8 and has an UI which is clear and well-arranged.
If you like to join a pool you can get a good overview on this page : https://explorer.burstcoin.network/?action=network_chart
If you want to help the BMF team and its activities, we recommend that you join one of the two pools of them.
The fees that the pools receive go directly back to the BMF Marketing Burst account and are only used for BURST Marketing, Bounties or other BURST supporting activities.
The two BMF pools are:
- 1% pool-fee – BMF0-100
- Recommended for miner which like to have „normal“ pool-fees
- 50% pool-fee – BMF50
- Reconmended for miner which like to spend 50% of the Blockreward to the BMF