Hi, just came in to reply one last time to clarify that I decided to abandon this thread completely.

Making empty accusations is easy, and some people here are bored enough to make them indefinitely. We have more important things to do than to debunk accusations made by people who don't even bother to read our replies.

If anyone has doubt about the viability of our project or thinks that it is a "scam", they are more than welcome to seek us out on Discord and see for themselves. or just move on to the next coin. I believe I left enough information in this thread to establish how serious this project is. Hence, I see no point in replying any longer.

Check out his post history, he is "legendary" because he helps people build rigs. No reason to believe he has any more grasp of the theory of cryptocurrencies than his, erm, porcelain throne. If he weren't a coward looking to stir up shit he'd respond to my very reasonable questions instead of picking fights with bystanders.

Do you have any actual critique of the tech? Our claims are very clear, can you point out which of them are "scam"? Does our code not do what we claim that it does? Are there any other coins which achieve what our tech already achieves (e.g. immediate confirmations on a pure POW chain)? I am all ears as to why you refer to me as a "scam artist".

An update and some clarifications

Update: a new version of the GPU miner has been released which improves CUDA mining performance by about 250%. It also finally introduces support for OpenCL, though it requires much more testing and optimization to be competitive.

Clarification: Despite the impression that some FUD trolls are trying to make, a large amount of red tips (as in a picture posted above) has literally nothing to do with a "51% attack", or any form of viable attack.

Red blocks are blocks which are disconnected from most of the network, they occur in several scenarios. In particular, a block which points to a very old block will be red. The picture above is the consequence of a scenario where a miner kept posting blocks pointing at old blocks (e.g. because they are getting templates from an out of sync node without realizing).

The picture is a few weeks old, where we first encountered such a scenario and realized that red tips posed a slight issue due to some bottlenecks in our reachability mechanism (that is, the mechanism which efficiently calculates whether one block is in the past of another block. This ingenious feat of CS theory and software engineering -- which actually solves a known open problem in a broad family of special cases -- was crafted by msutton, the same person which a certain FUD troll has tried to portray as someone who "does not understand why confirmations are needed" lol).

These bottlenecks have been fixed two versions ago and have been thoroughly tested against amounts of red tips two orders of magnitudes larger than the picture.

Every once in a while an inattentive miner does cause an increase in red tips and this has not caused nodes to increase CPU usage, whereby spamming red blocks is not even a viable CPU attack anymore (not to mention a "51% attack").

People who infer that a couple of hundred of red tips imply a 51% attack probably haven't even a vague understanding of GHOSTDAG and could be safely ignored (this argument is easily quantifiable. Red tips can be as old as three days before they pass the pruning point and get deleted. Our network makes one block per seconds, so a pruning Window is about 250K blocks. In the scenario depicted in the photo, there were about 500 red tips. Hence, to create this amount of red tips it suffices to hold about 0.2% of the global hash rate, which we agree is quite far from 51%).

Just to be clear, even in the old "problematic" version, in order to actually choke nodes on CPU attack the adversary would have had to waste hashes equivalent to at least 1k blocks (though, in the difficulty target of three days ago, so it might be slightly cheaper than 1000 current blocks). After the update this seems to not be a concern even if an attacker spams ten times that much and more, even for nodes running on weak CPUs. We have no indications that any amount of red tips poses an issue.

For more details, you are welcome to peruse the lengthy discussions we had about this issue in our Discord server.

I addressed each and every one of these points (though I will have an update regarding 1) in a couple of days). You just ignored everything I said and called it a "bunch of excuses" proving that responding to you is a waste of energy.

The blatant lie was "discord dev wallet holders didnt know why blocks need confirmation etc. ".

You have consistently proven that you are just looking to undermine us at all costs rather than having this discussion in good faith, so I am not going to reply to you any longer.

Yeah, I obviously lack "skill" as is reflected by my lack of familiarity with Discord features. Discord boosts are obviously quintessential knowledge for any cryptocurrency designer and developer and not being familiar with them indicates general incapability 

(I won't respond to your other "points" as I already addressed some of them and the rest are just blatant lies)

He's just a FUD troll (seriously, check out his posting history) who can't spurt a single sentence without contradiction themselves. On one hand, our GPU miner is shitty beyond reason while oBTC's is awesome, on the other hand the oBTC FPGA miner "only requires a small modification". So when considering GPU, the miners are completely different and cannot be adapted easily, but when considering FPGA, the difference suddenly becomes "a simple modification"? Sure buddy you make a lot of sense and exhibit superior consistency.

There is an explorer (http://katnip.kaspanet.org) it might need a lot more work but there is nothing "improper" about it.


Had you read the thread you would have known that we implement block pruning, which means that there is no genesis block. The oldest stored block is three days old. Alongside we keep the UTXO set of that block and a cryptographic proof that this is indeed the UTXO set of a chain of that weight. This proof is an adaptation of the techniques developed here: https://eprint.iacr.org/2021/623.pdf


Like in most coins, any person can derive virtually infinitely many public keys for their wallet, and it is infeasible to tell whether two addresses belong to the same wallet. Therefore, "whale wallets" and "rich lists" are garbage information and are useless to track.


Due to the high block rate, home GPU and even CPU miners can still mine and expect their fair share. Even at three times the current hash rate, a single average home CPU can mine a block every three days or so, which means that if they mine for just a few weeks they will almost surely get their expected share without having to join a pool (for example, if Bitcoin had the same hash rate, then the same user would have to wait about 5 years before they see their first block, which means they would have to mine for decades to get close to their expected share). The fact that solo mining is still profitable in increasing hash rates is a feature, not a bug. When we reach a hash rate where pools make sense, they will be created by the community. If anything, the lack of pools indicates that the coin spread is more egalitarian. Pooling is a necessity which rises when the expected time for a single block for the average user becomes huge. After we increase the block rate to 100 bps, even if we ever reach Bitcoin magnitude of hash rate (which we won't even in the fantasy script where we become as popular as Bitcoin, as our hash is much heavier), very small pools would still be profitable. If


GPU miner is community driven, currently we don't have reason to suspect covert optimized miner. If in the future we will suspect differently we might try to help the community improve their miner. None of us is a GPU developer, and we have no reason to believe we can optimize the miner better than the community.


I don't use Word, I use vscode. The website is ugly, yes, thanks for the valuable input. I updated it. It is still ugly but now it include links to both HH and GPU miner. At least one of your comments wasn't useless.



We prioritize stabilizing the node, stress testing and increasing the block rate over listing and PR. It makes sense to us that we get a firm grip of the capabilities of our coin before making extravagant claims or encouraging people to sink their money into it. We know that it is very common in the crypto world to make baseless claims and worrying about partially covering them later, but we have a different approach. That being said, any community driven PR efforts are welcome.


If you are going to make baseless accusations, at least go with accusations that make sense. If we just wanted to fill our bag and pump the coin in exchanges we would not have chosen a fair launch model. We'd premine the shit out of the coin and then list it ASAP. If you see our careful conduct as an attempt to make a quick buck, then your conclusion was probably predetermined.

Aren't you the same guy that a few replies ago lied about the fact that the coin is in test net

This BCT thread was created by a community member who said they would maintain it and has since vanished, it was not created by the core team, and we are too busy to update it. The Discord server is our main outlet for core team and community update. Since we have no premine etc. we have no funds to hire fancy PR and marketing teams, so it is up to the users to stay updated. As I said, since this is a community project it is more of a DIY experience  

I will make a post in the Discord asking community members to try and better maintain the BCT thread, but I can't guarantee anything.

I just want to remind everyone that our approach in Kaspa was to involve the community ASAP. We didn't do any premines or airdrops or kept the network closed in any way, but rather announced it to the public as soon as we had a running mainnet.

As a result, engaging Kaspa at this primordial point of its existence is a bit of a DYI experience We didn't have time and resources to develop GUI wallets, write extensive guides, or mount a professional looking network.

We hope these efforts will come gradually from within the community, in exchange for our efforts to make coin dispersion as egalitarian as possible.

Hi, I am from the Kaspa research team.

All and all we store three components: full header data above the pruning block, the UTXO set of the pruning block, and a proof of correctness for the UTXO set.

We have a fancy pruning mechanism (cf. https://research.kas.pa/t/some-of-the-intuition-behind-the-design-of-the-invalidation-rules-for-pruning/95) that allows us to remove old block data. At full capacity the size of a block payload is bound by 100kB and the size of a block header is bound by (100 +32*log_2(past size))B. In the distant future where we have a trillion blocks in the network (this will take about 30 thousand years of one block per second) we will have that log_2(past size) = 40, so let us assume that log_2(past size) <= 40. This means that the header size is bound by (100+32*40)B which is just below 1.5kB. For simplicity assume for now that he entire block size is 100kB. We store three days worth of full block data which, at a rate of one block/second, accumulates to about 26GB (note that this bound assumes that all blocks are at maximum capacity, no assumptions on average number of txns per block).

The UTXO correctness proof (cf. https://github.com/kaspanet/research/issues/3) requires that we keep additional log_2(number of blocks in the network) headers (not full blocks). Using again the assumption log_2(past size) <= 40  this adds about 60kB of data, which is completely negligible. Currently we store all block headers, as it requires some care to remove them without accidentally removing headers required for the proof and our dev team hasn't got around to this yet, this is a completely technical issue which will be resolved in the near future. (There is another detail I swept under the rug, which is that we also have to store the headers of all pruning blocks. This means one header per day. While this technically grows at a rate O(n*logn) the constant is ridiculously small: it is bound by 1.5kB/day, which are about 570kB a year).

The only thing that grows linearly is the pruning block UTXO set itself. It currently requires a field of a fixed size for every unspent output in the network. It is hard to predict how fast this set grows as this heavily depends on user behavior. We will resolve this in the future by means of cryptographic accumulators (cf. https://en.wikipedia.org/wiki/Accumulator_(cryptography)). An accumulator is a way to represent a large set succinctly such that it is impossible to recover the set itself (due to information theoretic compression bounds), but it is possible to verify that an element is in the set given a proof. This means that every user will only need to store the (proofs of) their own unspent outputs, and the nodes will only have to verify this proof against the accumulator, which is much smaller than the actual number of unspent outputs. The sizes of the accumulator and the proofs depends on the exact solution we will choose.

---

I feel that I should clarify: the bot in question was written by a community member which is not a member of the core team and who does not want to share their code, and I am sure they have their reasons. This has nothing to do with Kaspa. All the bot does is to issue a couple of commands to our (completely open source and publicly available) node and print the result to a Telegram channel. Seems a bit unfair to me to conclude from this that the core team is holding back on anything.

We strongly believe in openness, which is why we made the network publicly available and invited the community to get involved as soon as possible, and in particular, without any premining whatsoever.

The reason we wanted to delay the announcement is because we wanted the coin to be more well tested, and the ecosphere more well developed, before using our one chance to garner attention off the BCT board. But since this is a community coin, we can't (and don't want to) prevent anyone from making announcements. Anyway, now that the cat is out of the bag feel free to ask me anything.