¶ Tokens and PoS related matters
¶ What is the Kaspa's contract address?
Kaspa is a L1 PoW coin, not a token, so no contract whatsoever.
¶ Are there going to be master nodes?
No, all nodes are equal. Kaspa totally isn't a PoS coin.
¶ Is staking possible?
No and it will not.
¶ Can I have a profit by running a node?
Nope, no direct profit. But it gives you the fastest ping for your mining, and a full control of the node and wallet functionalities: you won't have to seek for a public node with the RPC port open, and won't need to hope it's healthy, well-versioned and non-malicious. This way you are also strengthening the decentralization and stability of the Kaspa network in general.
¶ Delegators, anything else from a PoS universe?
No, purely PoW philosophy, Kaspa is Nakamoto's spiritual heir.
¶ Maybe NFT?
Nope. Maybe on L2.
¶ Why is Kaspa better than PoS coins that don't use much energy, are also "very fast", and have smart contracts?
Proof of stake (PoS) systems end up being much more centralized than many Proof of Work systems for the following reasons:
- PoS creates a "rich get richer" system -- the more coins you hold and stake the more voting power you have to create new blocks. These tokens also earn more coins through staking. Since these individuals don’t need to expend resources to stake (unlike in mining), they can simply increase their overall staking amount as they earn more coins from staking rewards, and exponentially grow their influence on the network over time, forever. With PoW systems you can't infinitely expand. There is a limited amount of energy / equipment / land leading it to be more decentralized also.
- PoS systems often have very few validators -- Many big name cryptocurrencies have as few as 21 block producers. A far cry from Bitcoin's thousands of nodes. This means it's much easier to get compromised. The main point of a cryptocurrency is to be immutable and decentralized otherwise it makes more sense to just use a database shared with 21 people.
Kaspa uses less energy than many other PoW coins because of the hashing algorithm used -- Optical Proof of Work
L2s are only becoming bigger and Kaspa will be able to support L2s and smart contracts in the future. It's important first to get a decentralized and secure base layer with less features. It's easier to build on top of secure bases than to make the base more secure after things are already built on it.
¶ L2s and smart contracts
¶ Does Kaspa support L2 features?
No. At least not yet.
¶ Will Kaspa implement smart contracts in the future?
When it becomes the ultimate L1, someone, or many someones, will implement L2 smart contracts over it. The Kaspa community will eventually provide any L1 support needed for a well thought design of L2.
L2 and smart contracts implementation discussions are led in the #smart-contract-brainstorming channel of the Kaspa Discord server.
¶ Patents and copyrights
¶ Is Kaspa tech patented?
Nope and it won't be.
Regrading the code: obtaining patents for anything goes against the ideology of open source, and Kaspa's code is open sourced, as well as of many of its ecosystem parts.
Research papers results aren't going to be patented as well, for scientifically-philosophical reasons of their creators.
Anyone going to try improving Kaspa ideas and techniques on their products are welcome to do so. It's just that this will require a very high level of expertise in many areas simultaneously, as well as consulting Kaspa theoreticians on many topics to be implemented correctly. So this will take much time and effort from the challengers, and, as a side effect of the result, will do a nice PR to Kaspa itself.
¶ Tokenomics
¶ What is the total supply?
Approximately 28.7 billion KAS which is a fixed supply with no plans to increase.
¶ What is the monetary policy?
The monetary policy has two phases:
- The pre-deflationary phase, that started at the mainnet start, Nov 07 2021, has already ended (at May 08, 2022). Reward rate was firstly random, in a range of 1 to 1000 Kas per block, for the first 2+ weeks, and then was replaced with the constant one at the 1st hardfork: 500 Kas per second. Since a blockrate was also 1 per second, that essentially meant the reward was 500 Kas per block. This stage lasted for 6 months.
- The chromatic phase started after that. In this phase block rewards geometrically decrease. The initial block reward was 440 KAS. The block reward halves once per year, but smoothly: every month, block reward is decreased by a factor of (1/2)^(1/12) (this means that the ratio of block rewards in consecutive months is exactly the same as the ratio of frequencies of two consecutive semitones in a tempered chromatic scale. The initial block reward is the frequency of the note A4, and every averaged year is hence called an octave). Here, a year (or an octave) is 365.25 days, and a month (or semitone) is exactly one 12th of a year.
Note that the policy dictates how many coins are minted per second regardless of the block rate. Should the block rate change in the future, the reward will be adjusted accordingly to maintain the same emission rate.
Here are some numbers:
- by January the 1st, 2023, about 15.3B Kas had been mined (53.3%);
- by January the 1st, 2024, about 21.9B Kas will have been mined (76.3%);
- by January the 1st, 2025, about 25.1B Kas will have been mined (87.4%);
- by July the 10th, 2026, about 95% of all Kas will have been mined;
- it will take about 36 years since the mainnet start for the block reward to fall below 1 Sompi that will essentially mean the reward is 0 (in the case the blockrate kept as is, namely 1 BPS. Otherwise the time will shrink for log2(new BPS) years, say if 32 BPS is established, the new zero-reward date becomes 36 – log2(32) = 36 – 5 = 31 years from the mainnet start) .
¶ Is there a halving phase schedule table?
Yep, here's the PDF. Notice the actual dates might swing a bit due to the network conditions: the start moment of every next phase is based on a predefined DAA score value, and the moment of achieving of one or another value of DAA score may deviate from its estimated date and time because of the total network hashrate fluctuations and thus the block generation pace fluctuations.
¶ Was there any type of ICO, vesting phase or something like this?
No. Only a publicly declared fair launch.
¶ Was there any kind of premine?
Nah. Fair launch model, a Nakamoto's philosophy.
¶ Is there any kind of fees?
Currently the TX fee is calculated as 0.0001 Kas per UTXO.
¶ Why am I seeing different max supply's in different places?
tl;dr: In a nut shell, the hard cap in the code is 29 billion but overall supply is an estimate, due to the halving schedule being on daa scores, rounding, original gamenet random rewards, and possibility for emission to reduce with faster block rates.
Elaborated:
- There was a "random reward subphase" during the first 2 weeks of the mainnet, where the block reward was pseudorandom in the range of 1..1000, with the expected average value of 500. But it turned out the avegare was more like 750 instead (still distributed randomly between miners though), hence about +300M to the estimated supply of the "stable reward" phase;
- The halving schedule is bases on DAA score calculation, an since in realtime the DAA score looks slightly different for each node (not all nodes know of all blocks generated at any given moment thanks to the DAG strucure where there could be more than 1 block mined simultaneously in the different ends of the Kaspa network), each node decided separately, whether it's already time for reward reduction or it is not yet. So miners on different nodes can have a different reward for their blocks during the phase change period (up to 18 seconds in total). This could give a sligh noise to the total emission, but that noise would hardly exceed tens of thousands Kaspa;
- Moreover, due to a parellel nature of DAG we can have an anti-chain of parallel blocks all with score exactly below the transition score. However there is a limit to the number of such parallel blocks being rewarded — namely the daa window size (2641 — very untight upper-bound indeed). So we can take 2641 blocks from every "month" and give them the reward of the "month" before, which is equal to simply adding 2641 extra blocks with current (this "month") reward. This could give another tens of thousands Kaspa;
- Sometimes DAA scores jumps up by a certain value thanks to blocks parallel creation, so the exact border of the reward switching could not be achieved, and this gives yet another swing in total emission, but it's too expressed in hundredes to thousands Kaspa at each new reward phase start.
So to conclude, the total emission may change within some small limits, but it is guaranteed to never reach 29 billion, and the most accurate value that is available for evaluation is given by the bot in the discord: 28,704,026,601 KAS in the period of 36 years from the mainnet start (November 07, 2022).
¶ Kaspa prehistory related
¶ Why Kaspa is a fair launch coin when its theoretical research was funded by Polychain? Why did they leave? Is Kaspa a scam?
Answered by Yonatan Sompolinsky:
DAGLabs raised overall roughly 8M$.
The project's initial business plan was to develop OPoW-like ASICs and sell and distribute their hashrate, as I described in some medium post. I thought of it as a good middle ground between decentralization and sustainability.
The fact that this plan failed is indeed a failure of DAGLabs as a for profit entity. The reason it failed was a combination of the immaturity of OPoW ASIC tech, and (my, together with Polychain's) assessment that pure fair launch is the only path to give Kaspa (and, in fact, any PoW coin) true chance at growing to meet its goals/dreams.
If you think Polychain's support of this is weird or even suspicious then you probably hadn't had the chance to engage with crypto VCs. As I said in Kaspa's Telegram group, crypto space has seen way more bizarre instances than a VC supporting fair launching over no launching.
See also screenshots.
Additionally, when the Kaspa mainnet went live in November 2021 there was already a decent size community. Anyone could have mined at that time.
¶ What's the history with mining hardware bought by DAGLabs, according to @Hashdag's Meduim article?
Question: Hashdag wrote in Medium article that they bought 'mining equipment' for the PoW to have an early advantage. What it was, why there's no any additional info?
Answered by Ori Newman:
Where was no specific answer given because the mining algorithm has no name. We just tried to cooperate with a mining company and develop an algorithm that will be very easy for them to develop ASICs for. I can guarantee to you that it had no slight relation to the current used mining algorithm (k-heavyhash).
¶ Why was the HeavyHash (oPoW) mining algorithm chosen? Was it so the devs could premine and control any hardware?
When Kaspa was designed (before the mainnet launched) the team thought that oPoW would be valuable in reducing waste and saw the potential in it and how it could potentially be more decentralized than the current ASIC mining. oPoW is also as secure as SHA256. The value proposition of energy-efficiency will materialize only when specific optical hardware became a thing, until then community members can still mine with CPUs/GPUs. To develop the hardware for this a external group (not connected to Kaspa) needed funding and funding required a live network to sustain it. Kaspa volunteered to be that network (made the first move). Later on the group developing hardware for oPoW dissolved and DAGlabs as a for profit entity also dissolved. As a result there was ultimately no premine or hardware specific to the developers or any insider group. Anyone could mine equally when the network launched (see above answers). Additionally the developers alone didn't just choose to use oPoW ,the community voted on it before the mainnet launched.
¶ How much Kaspa does DagLabs or Polychain capital have?
Less than 3% of the total supply (840,000,000 KAS). See here
¶ DAGLabs existence, actions and earnings history
- DAGLabs founded in 2018 by Yonatan and backed by (mainly) Polychain and (lesser) Accomplice and Genesis Mining investments in the amount of 8M$ to implement GhostDAG protocol in the opensource code of the coin, and to develop (and later sell and lease) an optical ASIC mining devices for that coin;
- by the mid-2021 it was decided there's no sense to continue funding the development since optical ICs are not ready for a factory-grade implementation and in general the interest to PoW coins is ceased in the cryptosphere, so by the agreed decision of Polychain and DAGLabs the project is henceforth stated as "owned by the community" while DAGLabs and Polychain waive any intellectual property rights;
- by the start of the mainnet (2021 Nov 07) DAGLabs still exists but in the half-sleeping mode, supporting several developer on a part-time basis and waiting for the mainnet launch;
- after a launch DAGLabs starts mining on the common grounds, slowly spending the remnants of the initial funding (in the amount of several hundred thousand USD) to mine Kaspa on a rented Amazon HW;
- by late-December the GPU miner is written by the community member @hauntedcook (and then later also in cooperation with @demisrael), so DAGLabs switches to another type of rental HW;
- mining on rented facilities lasts for about 5 months, after which the finances are finally exhausted;
- these mined coins, in the amount of not more than 3% (probably close to 2.5%) of the max supply (i.e. obviously <850M Kas) are shared between investors (Polychain at al) and the former employees, advisers etc of the DAGLabs in some proportion;
- DAGLabs is officially closed after that (took some time to dissolve a legal entity; wasn't operational at all during that time).
Source links:
https://discord.com/channels/599153230659846165/916662870379491328/1046886450601398393
https://discord.com/channels/599153230659846165/916662870379491328/996761363894509568
https://discord.com/channels/599153230659846165/909907923084382218/996054649410953226
https://discord.com/channels/599153230659846165/909907923084382218/996047610651627551
https://discord.com/channels/599153230659846165/909907923084382218/995774105712337026
https://discord.com/channels/599153230659846165/916662870379491328/991123684385361951
https://discord.com/channels/599153230659846165/916662870379491328/990897783475163136
https://discord.com/channels/599153230659846165/916662870379491328/990893756591001640
https://discord.com/channels/599153230659846165/916662870379491328/990739452622163989
https://discord.com/channels/599153230659846165/916662870379491328/990736859791523850
https://discord.com/channels/599153230659846165/916662870379491328/955793396268687380
https://discord.com/channels/599153230659846165/610815395527393301/954060451145203813
https://discord.com/channels/599153230659846165/610815395527393301/953621816205799445
https://discord.com/channels/599153230659846165/916662870379491328/939960107771518996
https://discord.com/channels/599153230659846165/916662870379491328/939913692722659358
https://discord.com/channels/599153230659846165/909907923084382218/924705390309019720
https://discord.com/channels/599153230659846165/916662870379491328/920271238088253450
https://discord.com/channels/599153230659846165/909907923084382218/911015989792108574
https://discord.com/channels/599153230659846165/599153231305637890/907943846699204621
https://discord.com/channels/599153230659846165/599153231305637890/906770708586197002
https://discord.com/channels/599153230659846165/599153231305637890/895617582856548372
¶ Wallet
¶ How to backup a wallet?
In KDX and webwallet you should've written down the 12-words seed phrase that was presented to you at the wallet creation. If you did not do that you'd better create a new wallet, backup its seed phrase and transfer you funds to that wallet from the previous one.
For the CLI wallet see here.
¶ How to import a CLI wallet from a seed phrase?
Run kaspawallet create --import, then it will ask you for this phrase, and you will need to enter it, all 24 words at once, separated by spaces. It must be 24-words phrase that you've previously got from running kaspawallet dump-unencrypted-data, not a 12-words phrase from KDX or web wallet: these phrases are incompatible.
¶ My CLI wallet balance is wrong, what's the matter?
Since it is the node that provides per-public-address balances for a wallet, it's 99.(9)% chance that some of that balances are calculated incorrectly. You should restart a node without --utxoindex flag, wait until it is fully synced, and then restart it with the --utxoindex flag. If it doesn't help then resync the node from scratch: remove datadir2 folder completely, start a node without --utxoindex flag, wait for a full synchronization, and then restart it, this time with the --utxoindex flag. Then check your balance.
Double check that you're using the same wallet as before, that you're not accidentally checking the balance for not the same wallet that was kaspawallet create-ed or --import-ed from a seed phrase. Make sure kaspawallet show-addresses shows you the same address(-es) you've been mining or receiving transactions to.
If it's still not ok, ask for help on a #help-wallet channel of Discord server.
¶ My KDX wallet balance is wrong, what's the matter?
Try importing your mnemonic into the online wallet or running KDX 2.8.7 and manually purging the data folder in ~/.kdx. Previous versions of both node and web wallet software libraries had various issues that so far have all been identified and resolved.
If this is a wallet used with an older version of the wallet libraries, try (in KDX or web wallet) going to the DEBUG tab and clicking Scan More Addresses. For example, the earlier version of kaspad had a glitch that could cause some transaction outputs to become not visible to the application layer. Web wallet also had some issues, one of which was new address generation during fee preview calculation in the "Send" dialog, which are really hard to replicate and thus hard to debug.
Generally, because of how wallets work, i.e. they derive a chain of addresses from your private key, the loss of funds is very unlikely. You have to either lose your private key or have your system compromised security-wise.
notice from 2021.01.11: with the latest version of NodeJS and the JavaScript CLI wallet is failing to start with nodejs giving the following error: Error: error:0308010C:digital envelope routines::unsupported This doesn't happen on previous versions of NodeJs. If you end up in this situation, until this is resolved, to mitigate, please run export NODE_OPTIONS=--openssl-legacy-provider (on macOS/linux) or set NODE_OPTIONS=--openssl-legacy-provider (on windows) before running kaspa-wallet. This applies only to the JavaScript CLI wallet, not the native Golang CLI wallet shipped with kaspad.
¶ Why can't I send the desired amount of Kaspa? The wallet says "transaction mass of NNNNN is larger than max allowed size of 100000"
The requested amount of Kaspa is collected into a transaction from the UTXOs (unspent transaction outputs) that you have at your disposal. If you got Kaspa by mining, then you have a lot of UTXOs of,say, 500 Kaspa each. But adding UTXO to a transaction requires a certain amount of memory to describe it, it is several hundreds of bytes. Yet the size of the transaction is limited, and the limit is 100000 bytes. This means that currently a transaction can fit not more that 84 UTXOs descriptions, so the guaranteed lower limit of Kaspa that could be transferred in one transaction is 84*500=42,000 Kaspa. But if you have larger UTXOs in your UTXO set (say, if you purchased some Kaspa from someone else), this limit might be much higher: it depends of whether the wallet will choose to use that UTXOs in your requested transaction (currently the CLI wallet chooses the largest UTXOs first).
If you want to send more in one transaction, you should manually "compound" your UTXOs beforehand: this is done by sending 42,000 Kaspa to yourself several times. You may send Kaspa to the same public address of yours that you've been mining too, it does not matter if the source and destination addresses are the same. This way you'll get several UTXOs of 42,000 Kaspa each instead of multitude of UTXOs of 500 Kaspa each. If you want to send even larger amount in one transaction, you can compound your funds even further, into, say, 1,000,000 Kaspa blocks before requesting the final transaction to the desired external address.
¶ There are so many differences between the old explorer, beta explorer and wallet, how to find out who tells the truth?
Generally the old explorer still knows the best 'cause it's keeping its own transactions database that's not pruned, while the beta explorer does not yet. And the KDX node is pruned every day so to keep only the last 3 days of transactions, so if you strop the KDX for more that a day you're risking of losing some transactions info (not your balance though, it's taken directly from the node by per-address basis).
¶ Why is the katnip explorer balance is different than the sum of transactions it shows?
There may be two reasons for this, but both are of the similar nature.
¶ Excessive rewarding transactions records at solo mining
It may be that you are mining solo and see, say, 3 entries about the reward for the found blocks in the explorer. But at the same time, the balance on the address is equal to the sum of rewards for just 2 blocks. The question is, what to believe?
This happens because the Katnip does not fully take into account the Kaspa block reward logic. The payout for the block you found is not given to you by the block you found, but by the blocks following it — those that made your block their parent. Each of them gives you a reward for the found block, but in the end, after the network reaches a consensus regarding the position of your block and its descendants, only one of these reward transactions remains valid — the one that executed by the block which turned out to be the element of the so-called selected chain, the "barebone" of the DAG. The remaining reward transactions are discarded, and the rewards accrued by them are not taken into account by the network (for more details, see Merging and rewards).
However, the explorer does not monitor the consensus state, because
- it is very difficult to do it on your own and
- it would have required to completely duplicate the functionality of the node in the explorer.
And the node in its current version does not provide the explorer with such information in a convenient form.
Therefore, you can see records for all transactions in the explorer, both those that were recognized as valid, and those that were eventually discarded. They're reflected in the list of transactions, and you can't tell from there which one is the valid in the end and which is not.
But the address balance in the explorer is taken from the node, where all these nuances are taken into account, so in the end it's the balance that is the true indicator of the number of coins you have at your disposal.
¶ Some coins have already been spent in outgoing transactions
The list of transactions of a certain address in Katnip only includes the incoming ones, that fill the balance of the address. But outgoing transactions that spend coins from that address are not shown in the list, so if some of coins have already been spent then the address balance will apparently be less that the sum of balances of incoming transactions.
To know if this or that of the transaction outputs have been spent you should click the ID of that transaction in the list and look for the Spents (N) line in the transaction description header on the appropriate explorer page, where N is the number of subsequent transactions that were spending UTXOs of the transaction in question. If there is that line then at least one of the UTXOs of that transaction has been spent, and that's the reason of the difference between the address's balance and the sum of transactions.
¶ Node
¶ How many nodes / miners are there?
As of August 21, 2022 there are around public 70 nodes active. There is an unknown number of node not accessible from outside (personal-use nodes).
http://kasboard-mainnet.kas.pa/?orgId=1&refresh=1m
As of August 8, 2022 the top miners are as follows:
1) kaspa:qr36zdxs0dn3n0h799jhdl02qks5742lxjgmfsfj9xmlca7n4l6mw0s0n48nx: 21.5%
2) kaspa:qrk9decfnl4rayeegp6gd3tc6605zavclkpud5jp78axat5namppwt050d57j: 18.9%
3) kaspa:qp0l70zd5x85ttwd6jv7g3s3a8llzj96d8dncn4zmhv4tlzx5k2jyqh70xmfj: 17.2%
4) kaspa:qqg0m2cq9nls4s2mlj9estz6v947l8j6vmcvv4057clh688088ftg7ce6p895: 15.2%
5) kaspa:qpay7sfnmw89n5sh6ltruc0v2kushh765nadgtn62562aslrt5632l78dclyw: 13.5%
6) kaspa:qzspny3tg0hda6nm7xl669knxxrtmr5mdtdf02z867875y8v8uy8yuq4xhd0j: 1.7%
7) kaspa:qpgq93dckz9ljp47qmlzuz67ltzsh6ad0qc5723qn23r666d52cr6jzznu332: 1.3%
8) kaspa:qpgjypq0jeuc5rc594y6vn7k7qkz3d7zttgty98h79khrt7ppnhfxjzh0p86a: 1.0%
9) kaspa:qrgl5h07jxwgcsm6tk80f9dpl4hllmwht5klnctanuhslcmcjv0evda89hg4t: 1.0%
10) kaspa:qzp4pmk70mk29a0mw0phuyj0qq74haemdu4v58yjl03fellmveyzu40f89w5e: 1.0%
11) kaspa:qq9lfv6r3pjfqgj7gfz2uveymgmh93t8wu8v3ua7p2u022kx825cwr9zpcaqf: 1.0%
12) kaspa:qz4rrvhdjqr0ku0kg76mwka8vy0mupuz9h8dkhmvle4le37wqmk22u0ny9nfn: 1.0%
13) kaspa:qp4layahzqfwwlcx5vssr7dujzutsylhu4uag5qkzzhh0sqvkpq7g7ak9g73q: 1.0%
14) kaspa:qqxzjspnt2hcesglpennw0x946dg7fejgfukyur26hz3gzkus6rgvp7hhveje: 1.0%
15) kaspa:qphfhh2ukva9n5kd0n0ps0femfwjqug6m65mx5ax49jemrjqvm757vds26k6x: 0.7%
16) kaspa:qrj4n2rcmuwv00cz07rdkdkxrtvwsqruc0s6z5q4rh9t8nunsx632qra7jue0: 0.7%
17) kaspa:qqqxuxsr3hu73durn84tyt8ykdkzty0l4x2y4shdtfk923wr2dcrjau9vh7hz: 0.7%
18) kaspa:qzqd8agc7sfm3je5l7agsj8klalxenjn287rha5xyxnlcv3h3nde2vtdleyyr: 0.3%
19) kaspa:qztf0v29fl3y27njgu5kt2veq9zp6u33qugskaue4qjzyv07ptzqqrq2snxyt: 0.3%
20) kaspa:qpl66y2dg2lxv7vgeuq2tfqfvevxp984sxnqnwgd472cwzyxekw6j3wjxh0mt: 0.3%
¶ How to know if node is synced?
You'll see multiple "Accepted block ... via relay" messages in the console output. See also a "Setting up a CLI node" article to know the synchronization stages.
¶ How to find a public node?
Run a command line (in Windows: press Win+R, then type cmdand press Enter ) and run one of the following commands there in its console window:
nslookup mainnet-dnsseed.kas.pa
nslookup mainnet-dnsseed-1.kaspanet.org
nslookup mainnet-dnsseed-2.kaspanet.org
nslookup dnsseed.cbytensky.org
nslookup seeder1.kaspad.net
nslookup seeder2.kaspad.net
nslookup seeder3.kaspad.net
nslookup seeder4.kaspad.net
nslookup kaspadns.kaspacalc.net
Each one should return a list of IP addresses. Each address corresponds to one of Kaspa nodes running all over the internet.
Note that not any such node is suitable for mining on it: mining requires node to have the RPC port open, and this may not be the case for a given node, because DNS seeders are only designed to provide to the newly syncing node the addresses to sync from. And for that the syncing source node must only have another specific p2p synchronization port opened (16111), not the RPC one (16110) that is required to operate with both miner and wallet. The only way to know if node allows mining is to try to connect a miner or a wallet to it.
As of kaspad v0.12.1 it is also possible to run the kaspactl command GetInfo -a -s <address of node>, if you get a response it shows the rpc port is open to the public, the command also displays if the node is synced and utxo indexed, if the queried node is of v0.12.1 or later.
Also please try to choose a node of these lists as randomly as possible: if everyone would start mining at the very first node that the very first DNS seeder gives out, that node would most probably be slowed down significantly, and may even crash. At the very least you'll have a strange errors appearing in the miner, mining (your and the others') will become unstable, and so this would be to everyone's disadvantage in general.
¶ How to use a DB bootstrap?
See here.
¶ Is there a way to have a profit from running a node? Can I run a master node?
No. All nodes are absolutely equal. Running a node increases the connectivity of the Kaspa network and allows you to have a minimal delays when mining.
¶ A node can't start, says error "...not in the selected parent chain", what to do?
Delete the node DB manually, or restart a node with a one-time --reset-db command line parameter, and let it resync from scratch. Don't forget to remove the --reset-db parameter before a next node start.
Note: As of Kaspad v0.12.2 this bug has been fixed. updating to the newest node version should stop the error from happening.
¶ Mining
¶ Mining errors
¶ Miner refuses to start, shows "Error: NoDevice"
You should have a proper GPU driver installed. Having only CUDA toolkit installed is not enough; moreover, CUDA toolkit is not required unless you're planning to recompile a miner's .cu files.
¶ Miner doesn't start mining on GPU, shows JIT or PTX related error
Make sure your drivers are newer than the minimal supported drivers
¶ Miner keeps crashing, reporting something about the network connection problems, although otherwise all network functions on an PC seems OK, what's that?
Lower you overclock settings, check GPU temperature, update your GPU driver to the latest version. This may seem totally unrelated but surprisingly really helps.
Make sure you don't have two computers with the same name (like HOME-PC) on your network: sometimes the router's DHCP system settings require that addresses be updated every, say, 2 hours, and the presence of PCs with the identical name causes problems in the IP address re-assignment process. If possible, set a (different) static IP address to each of your rigs.
¶ Miner crashes with GPU thread ... crashed: "an illegal memory access was encountered" message
This is usually due to a too high overclock setting, try lowering you GPU OC values.
¶ Miner's hashrate decreases after a while when I'm not connected to the remote machine; reconnection makes it raise back
This seems to be something to do with GPU power saving settings. It is suggested to run "Paint 3D" or some OpenGL enabling application in this case, that should address the issue.
¶ Mining optimization
¶ Is dual mining (CPU and GPU) available, or does it have a negative effect?
It is possible (use -t <number of CPU cores to mine at> syntax, i.e. -t 4) but it doesn't really make sense: CPU mining gives you about +1Mh/s per core, while with even as low-grade a GPU as 1050Ti you're getting around 100 Mh/s on it alone. It can also significantly reduce your GPU mining speed if you have few cores (e.g. 2) and several GPUs: it takes a certain amount of CPU power to manage and load GPU threads, and CPU mining aggressively consumes this resource.
¶ Is there a way to optimize CPU usage on a multi-GPU rigs with a slow or low-core CPU?
You can try running one miner instance per GPU to have as many miner instances as there are GPUs in the rig. Use the --cuda-device (or --opencl-device) option to specify which miner instance controls which GPU in the rig.
¶ What is the optimal workload value for GPU mining?
The default value (16) is good enough albeit a bit conservative. You may choose to set a higher value, which increases a hashrate (people use values up to 4096), but there comes a question: increasing the workload for a little more hashrate has a tradeoff on submission latency, because work chunks are less granular. Latency of say 0.5 sec usually will not effect the blueness of the mined block, but does reduce the chance of being a chain block, thus reducing the chance of merging red blocks and earning their reward. So the system in essence incentives maximal responsiveness (minimum latency). Thus the optimal value lies in the range of 256...1024.
¶ Pool mining
¶ Why do I have many shares a minute the first minute after joining a pool, and then the shares acceptance speed drops significantly?
This is the way for the pool to know your real hashrate. The pool starts at low difficulty, then adjusts up the difficulty over time for each miner to find a few shares a minute. The pool difficulty does not affect profitability.
- Solo mining always uses the difficulty set by the network, which is adjusted to 1 block a second on average over all miners participating;
- A pool needs to always know your real hashrate and so it gives you less difficult tasks to process. Then it only chooses to further broadcast those of your solutions that fit the total network difficulty criteria — and you'll eventually have one, 'cause it is just a matter of luck for your solution to have a hash that's not simply less than the pool's difficulty, but, by accident, a network's difficulty too;
- But there is a tradeoff for a pool: lower difficulty per share means more shares and more accurate estimation, but on the other hand — more CPU wasted on network instead of validating miners' solutions;
- The heuristics most pool use is 10 seconds per share (or the minimum diff between diff for 10 seconds per share and network diff);
- To know what difficulty gets you 10 seconds per share requires an initial estimation of the hashrate (starting from some fixed starting diff) — that's why your initial accepted share rate is visibly higher.
¶ Other
¶ Who are the top miners? How decentralized is the mining?
See here
¶ What is the mechanism of automatic donations in the mining software?
Consider every time the DAG changes to be a job. This job is updated on average every second. When the user specifies for instance 1% to dev fund, then every 100 jobs the miner mines one job over the dev fund address. If it finds a block during that time, that block's reward goes to dev fund.
¶ How to update HiveOS Nvidia drivers to the latest one?
There's an article about the subject.
¶ Mining Algorithm Opinions
¶ KDX
¶ Why is my KDX balance wrong?
Tracking the balance of the HD wallet is somehow complicated task in Kaspa, so sometimes KDX reaches certain limits in the search process and needs some user help.
The only really available options to see the correct KDX balance — after waiting for the DAG to have been 100% synced — are:
- restarting the application;
- clicking "Scan more addresses" in the "Debug" sub-tab of the "Wallet" tab (give it time to process, it scans 10,000 new addresses), and
- resyncing from scratch by clicking the "Reset data directory and resync" button in the Settings tab, when its Advanced mode checkbox is checked (normally syncing takes not more than 2 hours, usually much less).
Basically a combination of the first two eventually helps.
¶ Why does my address in KDX change every time?
It's for increased security of your privacy, so no one could link your different payments (sent or received) to a single entity, i.e. you. It is also changed because once you have used an address to send or receive funds, it is considered to be weakened cryptographically by 2/3rds, so this is a standard practice for UTXO-based chains like Bitcoin, to which Kaspa belongs as well. The KDX changes the address every time it detects it is used, but it doesn't invalidate these addresses, they keep being absolutely functional, specifically you can continue mining to the same address as before, regardless of what KDX currently shows you.
This is also true for the web wallet: KDX and web wallets share the same codebase in many aspects.
Basically, a new change address is generated whenever coins are going off that address, and the amount being sent (+its fees) isn't strictly equal to the sum of UTXOs used in tx
The remnants of that sum - the change - is sent back to the wallet but not to the address of the origin; instead it's sent to the newly generated change one, that is related to the origin one in the sense of keys derivation sequence
¶ KDX in the "Kaspad Node" mode doesn't start properly, its log shows [ERR] KASD: Unable to start kaspad: not found
Probably KDX started two kaspad processes. They are fighting for the resources or something. Try to forcibly close one of them.
¶ My KDX refuses to start, how to fix it?
- Uninstall it;
- Remove the following folders completely:
%localappdata%\kdx,%userprofile%\.kdxand%programfiles%\Kaspa\KDX; - Reinstall it.
If there is any recommended patch to Kaspa core files exist (see Discord server's #announcements channel), download it and replace the appropriate files in the %programfiles%\Kaspa\KDX\bin\windows-x64 folder.
¶ Is there an option that the KDX wallet will not use dozens of GBs of the disc space?
Click the "Reset data directory and resync" button (see the screenshot) each time you feel the KDX has become too fat. Say, every couple of weeks. It will resync its database from scratch. This operation won't affect your balance, but maybe you'll have to give KDX some time to find your balance back, see "Why my KDX balance is wrong?".
¶ What does "Compound transactions" do when clicked in the KDX/kaspanet.io wallet?
If you pressed it, did you lose your coins? Absolutely NOT. It might however take a few seconds or even minutes for them to be visible again. Click "scan more addresses" to speed up the process. See also "Other ways to deal with KDX/web wallet troubles" topic down here on this page.
Long answer:
It combines your many 500-Kas (or however-many-Kas — 440, 415, etc., since the deflationary phase started) UTXOs (unspent transaction outputs) acquired by mining, into less number of larger UTXOs. Actually it tries to combine as many UTXOs of whatever size as possible into larger UTXOs.
This is useful because when you try to send some Kaspa via a transaction, the amount you want to send must be gathered of these UTXOs — say, 1500 Kas will be described as "take coins from this, this, and this UTXO of 500 Kas each and send them to <address>". Yet describing each UTXO requires about 1 kb of data to be inserted into the transaction body, and the maximum size of the transaction body is 100 kb. Thus you can only put about 85 UTXO descriptions into 1 transaction. And this limits the amount of Kaspa that you can send via 1 TX by the number of coins in UTXOs you have in possession.
Sometimes your compounded coins could have seem lost, as they're not reflected on your KDX balance immediately. But there's nothing to worry about, it's simply that KDX isn't aware (yet) of the balance of the address the coins were sent to, but it will over time. You may though need to click "Scan more addresses" button in the Wallet tab for KDX to know about the appropriate address's balance. The reason is, KDX wallet is the HD-type wallet that can have a vast amount of private/public key pairs (addresses) chain-generated from a single seed phrase, and when the coins are compounded, they are sent to one of the next addresses in the address derivation chain. Sometimes this address lies beyond the set of addresses that KDX is currently aware of, so "Scan more addresses" is needed to generate more addresses, beyond the limit that's currently known to KDX, and check if any of them have any non-zero balance, to reach to the address that the compounded coins were sent to.
¶ I'm getting error 'Rejected transaction ...: Transaction ... is orphan, where allowOrphan = false' when trying to compound. What should I do?
Up to at least version 0.11.17 inclusively there's still a bug in the kaspad that eventually prevents both KDX/web and CLI wallets from sending and compounding coins after a certain number of such operations.
In the newer versions of the KDX there's a "Reindex UTXO" button that fixed this problem for a certain while. Use it again whenever necessary.
Historical ways to fix it are the following: faster but more complicated way is to
- stop KDX completely (not letting it continue running in the background);
- start a CLI node and make it chew up KDX's node data folder (i.e. start it with a parameter
-b %USERPROFILE%/.kdx/data/kaspad-kd0) while being run without the--utxoindexparameter, to reset the utxo indexing data in that folder; - wait for the CLI node to start "Accepting blocks...", stop it;
- and start KDX again.
But that requires a bit of a hand work.
Slower but easier way is to:
- stop KDX completely (not letting it continue running in the background);;
- open the Windows Explorer window, put a
%USERPROFILE%/.kdx/data/kaspad-kd0line in its address bar, press Enter; - you'll get into the KDX node data folder, delete it;
- start KDX again.
Voila!
¶ Is there a reason that transactions show in my wallet completely out of order?
They are not out of order. They are "sequential" from the standpoint of what the wallet sees. However, if the wallet is not online at the receipt of transaction, it might not see it when comes back online, furthermore, there is a 3-day pruning period following which it will definitely not see it. If that occurs the balance will just increase.
Perhaps we should record increasing balance as a "phantom" transaction :), but we haven't done so (yet). The only way to access this data is via an archiving block explorer. Wallet or node can not track this data (it's too much data to keep as given high-speed of Kaspa, it produces gigabytes of data per week). Whatever transactions the wallet sees are stored in local cache, which also means that if the wallet is restored someplace else, the transaction data won't be there).
Technically speaking the wallet could be integrated with an archiving block explorer to fetch this data, but the community-ran explorer wasn't quite there when the wallet was made and at times is not very stable with accounts that receive a lot of transactions (I.e. mining) and we can't really make a server-side caching solution because it would require kaspad node to be always online, which can be done with some redundancy but is very complicated.
¶ Other ways to deal with KDX/web wallet troubles
For the web wallet:
- Try Ctrl+Shift+I to bring up dev tools and then right click on reload button and select last option "Empty cache and hard reload"...
For KDX:
- The only really available options to see the correct KDX balance are: restarting the application, clicking Scan more addresses in the Debug sub-tab of the Wallet tab, and resyncing from scratch by the "Delete database" button in the Settings tab, when its Advanced mode checkbox is checked. Usually a combination of the first two eventually helps.
¶ Trading
¶ How to swap between ERC20 (Polygon), TRC20 (Tron), BSC20 (BNB) and other USDTs?
Use any large exchange: Binance, Kucoin, FTX, they allow USDT deposits and withdrawals in any networks independently.
¶ Why is Kaspa not on more Centralized Exchanges?
Kaspa is a community project. CEX (Centralized Exchanges) are open to list projects, but for a (usually) substantial listing fee. The community has previously funded some listings. But for now, it has decided to halt new fundings for new CEX listings. This does not mean we will not do it anymore in the future. Also, if an exchange should be adding Kaspa free of charge we are always happy to help.
¶ Kaspa and Flux
¶ What is the benefit from running Kaspa node on Flux?
Depends on the point of view.
If you're the Flux node owner (i.e. you have staked some Flux coins, 1000+, and have registered your PC/sever with 8GB RAM, 4 cores, 100 Gb SSD, 10 Mbps internet connection etc., what is it required there to be the Flux node), and someone's running a Kaspa node (kaspad executable) on your Flux node, then you're getting paid for that in Flux coins. That's your benefit.
If you, on the contrary, want to run a Kaspa node on the Flux network, using its cloud-like structure, then you're taking a benefit of having your Kaspa node run on a hot-reserved reliable distributed infrastructure, that guarantees you the stable and load-ready instance of running Kaspa node. You can mine to it then, or have it as a background service for your own mining pool (if you have one somehow), or your Kaspa node-based site or whatever. But you'll have to pay for it in the Flux coins, to the Flux system. As long as you pay (it will be about ~5$ worth of Flux per month for a Flux node configuration that's acceptable for a Kaspa node to run), you will have your Kaspa node on and running.
But there's no way you can gain any direct profit from running specifically a Kaspa node on someone's (or your own) Flux node.
¶ How to run Kaspa node on Flux?
Click here to download the guide from Kaspa official site.
¶ Kaspa and Kadena
Since there are many questions of what are the differences and similarities of Kaspa's and Kadena's approaches concerning DAG, one of Kaspa theoreticians, Shai Wyborski (@deshe), conducted a comparative analysis of the solutions offered by Kaspa and Kadena, and issued the result in the form of a thread of tweets here. For convenience, here's the full text of that thread:
Recently I see a lot of buzz around the comparison of $kas and $kda.
While I do not think small cap projects should compete, I feel urged to clarify why I believe that, ultimately, $kas is the superior tech. Keep in mind that I am naturally very biased in favor of Kaspa having spent a decent part of the last four years helping develop it. I will do my best to keep my bias in check and be as impartial as possible, but I'm only human.
I also want to stress that I mean no disrespect for the $kda team and tech. They are esteemed researchers and colleagues whose work I appreciate greatly. In cryptocurrencies there are no solutions, only trade-offs, and I want to explain why my personal opinion is that Kaspa's trade-offs are better.
I think the main disadvantage of $kda is in its sharding. Sharding essentially means that each chain on chainweb is an autonomous economy. The way Kadena interconnects the chains means that in order to double spend in any of the chains, an attacker must be computationally comparable to all chains combined. That is a very neat feature, as it allows to make many parallel chains without compromising security. The huge disadvantage is that, since any chain is an autonomous economy, the latencies of the network are the latencies of each chain. It might be the case that the Kadena network creates 100 bps on 10000 chains, but in order to spend a transaction, you have to wait for a block on a particular chain. Each chain individually still has to be secure and is thus subject to the usual limitations of Nakamoto consensus, especially that the block delay must be orders of magnitude longer than the block propagation delay. This means that, no matter how Kadena is scaled, the long confirmation times remain fixed. This also means that every application developed on the Kadena network must run independently on any chain (or, run it on one chain, but then users must spend their money to that chain before they can use the service). This means that while kadena manages to scale bps, it cannot scale services or response times.
Kaspa, on the other hand, has none of that. The network is not sharded and the consensus protocol doesn't require any form of block delay to remain secure. This is why we already see Kaspa provide much shorter confirmation times while creating more blocks.
The main (perhaps only) advantage of kda over kas is its L2. They have a smart contract infrastructure called Pact which seems interesting enough (though I am not a smart-contract developer so I can't really tell). This makes it more readily adoptable. The crux is that it is possible to develop smart-contracts and other L2 applications on $kas, and I believe this will happen in due time. On the other hand, $kda could never achieve the responsiveness of Kaspa without completely redesigning their consensus layer (whereby actually becoming a different tech), which is why I think Kaspa is the superior tech.
¶ Miscellaneous
¶ Where is the rich list?
¶ Why is it there so many addresses in the rich list but only 12k followers on Twitter?
Because a wallet contains many addresses. This is by far not unique to Kaspa. Practically all Bitcoin wallets are HD wallets that automatically derive a fresh public address for each transaction. While it is true that there is some address reuse, it is considered best practice to only accept funds to an address once. The number of non-empty addresses typically increases quite fast, as in the common case the amount of money you transfer is smaller than the amount of money in the output you spend, so the difference is spent to a new change address, thus one address spent makes two new addresses.
¶ How to install a GCC for Windows?
See this really brilliant article.
¶ Where can I Trade Kaspa?
There's a separate article about it.
¶ Isn't mining Kaspa bad for the environment?
Kaspa uses less energy than many other PoW coins because of the hashing algorithm used -- Optical Proof of Work -- to eliminate energy as the primary cost of mining and instead make it concentrated in hardware (capital expense-CAPEX) rather than electricity (operating expenses-OPEX). Ideally in the future mining would be done with lasers (not invented yet).