Testnet 13 dk, testnet 14 100bps?

hello, i'm looking for kaspa node testers to assist me in testing this - much progress has been made since my post in 2025 and i'm ready for mainnet testing. if you're technical enough to do this (or have AI to assist you - it's not hard), have a spare computer (or spare compute on your vps) to run an additional kaspa node pls join me here 🙏 t.me/kasparnd/5090/15610 thanks

$kas, let us fix a common misconception: 10BPS will not make confirmations 10 times faster. It will make them somewhat faster, but not 10 times faster. How faster? Depends on how much confidence you want. As you wait for more confirmations, the block delay becomes more dominant over the block delay. For an exchange waiting for 1800 confirmations, the confirmation will indeed be ten times faster*. Because less than a minute after the block of interest was created, all new blocks will be in the future of the block of interest, adding to its confirmation count. But for everyday use, seeking 10-20 confirmations, the improvement will be much milder. Why? Because accumulating the first few transactions will take just as long regardless of block rates. It takes time for the entire network to learn of the block of interest, and during that time, what matters is not how fast blocks are created, but how fast block creators know of your block so they can point to it. * That's assuming that the exchange will still wait for 1800 confirmations after the upgrade, which is unlikely, since the entire motivation for waiting so long is to avoid 51% attacks, and not 49% attacks. See here: nitter.net/DesheShai/status/17468… The attached diagram illustrates this (though I must stress that it is an illustrative, hand-made diagram, that is not based on measured data, so please don't use it to make any quantitative claims about confirmations in Kaspa post-Crescendo). In the diagram, the horizontal axis is used as time (unlike KGI, which snaps parallel blocks next to each other and discards their time differences). The network delay manifests in the DAGs in that arrows (projected to the time axis) are never longer than the network delay, but are typically not much shorter either. You can see that even though many more blocks are created in the bottom diagram, the confirmations for tx accumulate pretty much the same for a while, and only start accumulating faster as we examine periods that are longer than the network delay. To conclude I will go on a tangent and remind you that there is a way to decrease confirmation times more meaningfully: the DAGKnight protocol. It's self-adaptive nature implies that a lot less of a margin of error is required when computing confirmations, making confidence accumulate much faster. However, increasing block rates and moving from GD to DK are two completely orthogonal tasks (at least from a theoretical POV, in practice I'm sure a lot of architectural insight went into designing RK to accumulate both).