https://kaspa-mdbook.aspectron.com/
KIPs are an organized way to suggest improvements to the Kaspa protocol. Because Kaspa has no central body anyone can suggest KIPs and if the community likes it, it will get funding. So far there have been 2 KIPs:
Or simply “virtual”, is a virtual block pointing at all current tips of the local node.
Blue score is the number of blue blocks in the local node's past from this node's perspective.
Difficulty Adjustment Algorithm — a moving window based algorithm that takes care of Kaspa mining difficulty adjustment to ensure the average blockrate is what is should be (1, 2, 32 per second, or whatever the current established value is). Window width is 2641 blocks (blue ones + those of red ones that fit inside the window, counting backward from the virtual's perspective).
DAA score equals to blue score + number of red blocks so far that were successfully merged and rewarded, and this number controls emission rate via DAA itself.
Every block has a selected parent (selected by GHOSTDAG algo).
virtual
is a virtual block pointing at all current tips of the local node.
Like any other block, virtual has a selected parent (aka the selected tip).
Starting from this tip, one can walk down the path of "selected parent" links, this is the "selected chain".
Note that by def the selected chain can change (since virtual point-of-view changes), it's called a reorg. In a wide DAG small reorgs are frequent, however security of GHOSTDAG implies that the chain is robust — meaning it stabilizes very fast up to a small suffix.
The selected chain is what determines the order of events in the DAG, and blocks in it (aka chain blocks) have a special role in the sense that we (recursively) accept their point of view.
The mergeset of a chain block C
is defined to be the set of blocks in the past of C
(i.e. reachable from C
) but not in the past of the selected parent of C
. Note that the mergeset includes the selected parent itself (which is the preceding chain block)
We say C
is the merging block of block B
in his mergeset.
We say C
is the accepting block for valid transactions coming from B
.
The GHOSTDAG order of a mergeset: sorts the mergeset in increasing order by blue work and tiebreaks by hash (lexicographically).
From the context of a chain block C
, each B
in the mergeset has 2 classifications:
B
blue ? meaning B
is well-connected and contributes to security;B
in the DAA window of C
(roughly speaking, blocks out of the DAA window are blocks which at least 45 minutes passed between their mining and publication times -- that is, they are highly disconnected).P.S. If a block is blue it is also surely in the DAA window (code does not assume that, but it's true). The selected parent is by def both blue and in the DAA window.
Every blue block B
is rewarded by C
in the following way:
C
calculates the coinbase subsidy based on the emission schedule and the current DAA score.C
sums up the fees from all accepted transactions which were included by B
Additionally C
rewards itself for every block R
in the mergeset which is red (non-blue) if it is in the DAA window of C
.
C
iterates the mergeset in GHOSTDAG order as defined above: for each blue block it appends an output entry to its coinbase tx with the calculated reward. If there are red + DAA blocks, it appends another output paying himself their reward.
If C
is not a chain block, then regardless of the fact that it performs all the same activities, its coinbase and self-reward transactions are not considered valid after the DAG structure is stabilized and thus discarded by each node.
So if you have a mined block hash B
, and you want to calculate the exact reward associated with it:
C
which merged B
B
is in C.MergesetReds
-> no reward.B
is in C.MergesetBlues
-> find the position i
of B
in C.MergesetBlues
. The i'th output in the coinbase tx of C
is the one paying the reward to B
.B
itself is a chain block and has merged red blocks which are also in the DAA window, then the coinbase of B
itself should have a last entry paying the miner of B
(one can validate this by checking that the coinbase has |B.MergsetBlues| + 1
entries).DAA window size is 2641 blocks.
Past median time window size is 263 blocks.
The transaction that is sent to a mempool is expired after 60 blocks that it's not included into blockDAG.
Right now (as of May 05 2022) it calculates as 0.0001 Kaspa per each UTXO utililzed in this transaction.
Yes, this is a wallet/node decision. The wallet decides how much it pays, but there's also an anti spam mechanism at the node that filters transactions with low fees. You can change the minimum fee via command line.
They will reject it from their mempool, but they won't reject it if it comes from a block. So if your node mines transactions with low fees everyone will accept them. So if for example we want to decrease the min fee, we can release an update and it'll be enough if most users will upgrade in order to work, and you won't be split if you don't upgrade.
Yes, this is theoretically possible.
If the mempool has enough transactions to fill up a block, the miner just selects the top paying transactions. If a transaction is above the node minimum fee it doesn't mean it's gonna be mined, it just means the node will add it to its mempool and relay it to its peers. The minimum relay fee is an anti spam measurement, and not a mining policy.
There were some discussions to implement something like this https://arxiv.org/abs/1709.08881 for a better fee market.
See this bit of a source code: https://github.com/kaspanet/kaspad/blob/dev/util/difficulty/difficulty.go
Here is the short description of how a Kaspa node network subsystem functions:
https://github.com/kaspanet/kaspad/blob/master/domain/dagconfig/params.go#L216
https://github.com/kaspanet/kaspad/blob/master/app/protocol/flows/v5/register.go#L50
TargetOutboundPeers
peers (which defaults to 8)
https://github.com/kaspanet/kaspad/blob/master/app/protocol/flows/v5/ping/send.go#L41
https://github.com/kaspanet/kaspad/blob/master/app/protocol/flowcontext/blocks.go#L125
https://github.com/kaspanet/kaspad/blob/master/app/protocol/flowcontext/transactions.go#L70