Bitcoin Forum
April 05, 2026, 05:31:45 PM *
News: Latest Bitcoin Core release: 30.2 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 [6] 7 8 »  All
  Print  
Author Topic: Cryptix Your Digital Currency for the Future Launch Now !!!  (Read 3491 times)
gwestcot
Sr. Member
****
Offline Offline

Activity: 818
Merit: 272



View Profile
March 31, 2026, 01:26:13 PM
 #101

Read: https://cryptix-network.org/hfa-fastchain-technology

Introducing HF-A (Fastchain) 🚀

While other chains compete on confirmation speed,
Cryptix makes transactions usable in milliseconds (10ms - 150ms)

I mean, it is possible to do instant finality in other ways via POS, Masternodes, or an avalanche pre-consensus. This method has serious tradeoffs in exchange integration and how costly it is to run a full archival node. I'm not saying it is definitely bad but everything has tradeoffs in this space.
ptaank
Jr. Member
*
Offline Offline

Activity: 77
Merit: 4


View Profile
March 31, 2026, 01:44:46 PM
 #102

Read: https://cryptix-network.org/hfa-fastchain-technology

Introducing HF-A (Fastchain) 🚀

While other chains compete on confirmation speed,
Cryptix makes transactions usable in milliseconds (10ms - 150ms)

I mean, it is possible to do instant finality in other ways via POS, Masternodes, or an avalanche pre-consensus. This method has serious tradeoffs in exchange integration and how costly it is to run a full archival node. I'm not saying it is definitely bad but everything has tradeoffs in this space.

Fair point, but HF-A isn’t trying to do instant finality like PoS or Avalanche-style systems.
There’s:
no second consensus
no validator trust assumptions
no liquidity or channel requirements

Basechain still handles all final settlement.

HF-A is only about making transactions visible and usable early, not final.
So it avoids trade-offs like:
validator centralization
complex setups for users
and harder integration for centralized exchanges

It’s not replacing consensus, just improving UX without adding those downsides

All-in-all, this is just the first step towards integrating Fastchain technology.
HoosatNetwork
Newbie
*
Offline Offline

Activity: 99
Merit: 0


View Profile
March 31, 2026, 05:42:15 PM
 #103

🦉 Kaspa transaction visibility ~1 second, what is Cryptix Claiming?🦉

HF_A is only a method to slow down mempool transaction propagation, because of a misunderstanding in Kaspa technology. I'm stopping giving free audits to Cryptis technology stack for now, but if he continues lying to his community about anything and spreading false statements of Hoosat Network I have more topics to audit and fact checks in the pipeline waiting.

Read more: https://medium.com/@toni.lukkaroinen/kaspa-transaction-visibility-1-second-what-is-cryptix-claiming-f23b0f0b21cd
red12345678
Member
**
Offline Offline

Activity: 70
Merit: 11


View Profile
March 31, 2026, 08:58:58 PM
 #104

HoosatNetwork is spreading false information and hate about other projects.
Perhaps, because his own project has completely failed.

A chart speaks louder than thousand words:
https://www.gate.com/de/price/hoosat-network-htn
ogrvar
Newbie
*
Offline Offline

Activity: 283
Merit: 0


View Profile
March 31, 2026, 09:31:57 PM
 #105

HoosatNetwork is spreading false information and hate about other projects.
Perhaps, because his own project has completely failed.

A chart speaks louder than thousand words:
https://www.gate.com/de/price/hoosat-network-htn

He spreads hatred towards false claims, liars and anonymous scammers.
FreshEgg95
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
April 01, 2026, 12:22:18 AM
 #106

You don’t need to deal with bloggers.
gwestcot
Sr. Member
****
Offline Offline

Activity: 818
Merit: 272



View Profile
April 01, 2026, 01:50:09 AM
 #107

Read: https://cryptix-network.org/hfa-fastchain-technology

Introducing HF-A (Fastchain) 🚀

While other chains compete on confirmation speed,
Cryptix makes transactions usable in milliseconds (10ms - 150ms)

I mean, it is possible to do instant finality in other ways via POS, Masternodes, or an avalanche pre-consensus. This method has serious tradeoffs in exchange integration and how costly it is to run a full archival node. I'm not saying it is definitely bad but everything has tradeoffs in this space.

Fair point, but HF-A isn’t trying to do instant finality like PoS or Avalanche-style systems.
There’s:
no second consensus
no validator trust assumptions
no liquidity or channel requirements

Basechain still handles all final settlement.

HF-A is only about making transactions visible and usable early, not final.
So it avoids trade-offs like:
validator centralization
complex setups for users
and harder integration for centralized exchanges

It’s not replacing consensus, just improving UX without adding those downsides

All-in-all, this is just the first step towards integrating Fastchain technology.

Ya but you are trading possible centralization for validators and just having a guaranteed centralization of node operators. Instant finality with a service layer seems ideal for real world usage so long as you have enough participants. The hard part is some of the sliders like the percentage of block reward split, collateral, etc. If you mess that up then yes, it can cause issues.
HoosatNetwork
Newbie
*
Offline Offline

Activity: 99
Merit: 0


View Profile
April 01, 2026, 03:32:42 AM
 #108

I'm not lying about anything, because logic does not change. Kaspa mempool blocks are visible in matter of ~5ms on another node and does not add artificial delay which your microblocks does. You guys can scream all you want, but logic and Cryptis won't change. As you guys don't heed my warnings, i'm going to release another piece in a moment.
HoosatNetwork
Newbie
*
Offline Offline

Activity: 99
Merit: 0


View Profile
April 01, 2026, 03:38:01 AM
 #109

🦉Does Lazy Validation of transactions Weaken “On-Spend” Attacks? 🦉

This piece talks little bit about how block rate affects Quantum onspend attacks that attack ECDSA transaction signatures and how FastChain which is decoupling block acceptance from transaction validation is in higher danger of "on-spend" attacks even if it did 100,000 Blocks per second, compared to Kaspa or Hoosat which do sub second block times with full block validation.  

https://medium.com/@toni.lukkaroinen/does-lazy-validation-weaken-on-spend-attacks-a9b1cc8e31a2
ptaank
Jr. Member
*
Offline Offline

Activity: 77
Merit: 4


View Profile
April 01, 2026, 03:44:53 AM
 #110

I'm not lying about anything, because logic does not change. Kaspa mempool blocks are visible in matter of ~5ms on another node and does not add artificial delay which your microblocks does. You guys can scream all you want, but logic and Cryptis won't change. As you guys don't heed my warnings, i'm going to release another piece in a moment.

I think you’re mixing two different design goals here.

Systems with instant finality (PoS, masternodes, Avalanche-style) achieve that by introducing:
- validator sets
- economic assumptions (collateral, reward splits, etc.)
- and often some degree of coordination or centralization

HF-A is not trying to solve that problem.
 It doesn’t provide instant finality
 It doesn’t introduce validators or service layers
 It doesn’t change the basechain security model

Basechain still handles all settlement.

HF-A is only about propagation and early usability, meaning transactions can be seen and acted on earlier, while finality remains unchanged. However Finality will come down (in ms) after Fastchain is fully functional in future.

So instead of: “guaranteed instant finality”

It’s: “early visibility + normal on-chain settlement”

That avoids the trade-offs you mentioned (validator coordination, collateral complexity, centralization pressure), but of course introduces a different challenge: handling pre-confirmation safely.

All-in-all, it’s not competing with instant-finality systems - it’s exploring a different approach to improving real-world UX.
HoosatNetwork
Newbie
*
Offline Offline

Activity: 99
Merit: 0


View Profile
April 01, 2026, 03:46:03 AM
Last edit: April 01, 2026, 04:35:17 AM by HoosatNetwork
 #111

No i'm not confusing anything. HF_A is only doing mempool transaction propagation and slower than Kaspa at that. I read Cryptis yesterdays code. Cryptis is bulling definitions out of his ass, as visibility of transaction is in two layers, visibility in a mempool and visibility in a block. The mempool transactions can not be cryptographically confirmed or finalized, as in settled. Confirmation and finalization requires addition to a block. Cryptis is comparing his HF_A mempool transaction visibility to Kaspa transaction social finality. As transaction in Kaspa are socially finalized in ~1s as it will have most likely have 10 confirmations, or at least 1 confirmation at that point.

Why to change practically instantenous mempool transaction propagation which is only affected by real world latency into microblocks and intents which contain those mempool transactions and delay their propagation to 50ms batches?

The next time Cryptis spreads bullshit about myself or Hoosat Network. Remember that he started CYTX copying HTN vision (Cryptis first research on Quantum safe mining (midstate hashing) is even based on my patent application) and that I'm publicly more experienced software developer, someone who is the first to implement DAGKnight to public testnet (open source, free of charge, in Golang).
Cryptix-Network (OP)
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile WWW
April 01, 2026, 05:19:59 AM
Last edit: April 04, 2026, 08:26:54 AM by Welsh
 #112

Hello Tonto from Hoosat. Your AI-generated Grok Medium article about HF-A is very embarrassing, because he clearly doesn’t even understand how it works—even though I explained it in detail.

You talks about a “quantum attack,” but there is no real attack surface. What is a quantum computer supposed to do—create transactions? Fine, that just means more fees for miners. Or a transaction-based DDoS attack? The system already accounts for that, and nothing significant would happen. In case of suspicious activity, the system would simply reject it. That’s exactly what the benchmark mechanisms are for.

You genuinely hasn’t understood what this is or how it works. That’s mainly because you doesn’t know Rust—it’s too difficult for you, and ypu only knows Go. On top of that, your Grok AI seems to have misled you. And since your English isn’t strong, you likely couldn’t even understand the documentation properly.

Your write:

"One of its core innovations is decoupling block acceptance from full transaction validation"
Complete Bullshit, HFA is a parallel, adaptive, optional way - its not a other way. Or how we could use it now without a Hardfork? The Consens is the same. He dont understand anything, its to high for him and his Grok AI. Can't you think that far ahead?

But ok, i explain it for non-developer like you:

The description of our HFA path as “lazy validation” is not accurate.

In our implementation, HFA does not lock first and validate later. The base transaction is fully validated before lock assignment:
- `rpc/service/src/hfa.rs` explicitly marks “Full base transaction validation” and calls `validate_mempool_transaction(...)` before status transitions to `Validated` and then `Locked`.
- `FastConfirmed` is a microblock-cadence state transition, not a bypass of transaction validation.

HFA also does not replace normal chain admission:
- After `submit_fast_intent`, we still submit through the normal basechain transaction path in `rpc/service/src/service.rs` (`submit_rpc_transaction(...)`), and set `basechain_submitted = true` on success.
- Normal submit/replacement paths enforce HFA fast-lock conflict checks, preventing conflicting spends while a lock is active.
- Active intents are revalidated and can be dropped if state changes invalidate inputs.

If the concern is about staged consensus processing, that is a separate pipeline behavior (`StatusHeaderOnly -> StatusUTXOPendingVerification -> StatusUTXOValid`) in consensus, and should not be attributed to HFA as “lazy transaction validation.”

So the precise characterization is: HFA is parallel/staged fast-intent processing with pre-lock full tx validation and ongoing revalidation, not lazy validation.

Now ask your Grok AI again, maybee you understand it then.

Next, there is a starting argument and an option:

--hfa-microblock-interval-ms-normal=
Defines the HFA microblock interval in milliseconds while operating in normal mode
Default: 50

That's the default value, why? So that weaker nodes can participate, but there's also the option to set it to 0ms, i.e., disable it. That's why it's a starting point. On our nodes/seeds, it's 0ms. This means, no, it doesn't slow things down. It's simply a safeguard for weaker systems; this is how you develop professionally, taking weaker systems into account.

And no, it's not a mempool; Furthermore, there would then be no 4000 lines of code for the system, as a mempool is already included. I clearly stated that. And no, it's not slower than other things. It's maximum speed. Why not measure it? Use the correct configurations and run a local test; then you'll see how fast it is. There is currently no transaction visibility system worldwide that is as fast as HFA. You need to read the code and use a better AI. Grok isn't very helpful for understanding it. Or you could try learning programming languages ​​so that you can actually understand code correctly.

I have better things to do than argue with incompetent wannabe developers who can't program. Focus on your Hoosat project; people have been waiting for years for your promised features like the marketplace, which doesn't have a single line of code. Or deal with the frozen wallets because you centrally interfered with the blockchain and stole millions of coins from users.

You're upset because I broke your hash, because I achieved a faster hash integration in my mining software in three hours than you did in a year. Because I showed how bad you are and that you don't even understand your own hash. And because I publicly documented the difficulties with the hash. That's the only reason you're so upset now.

But you should learn to program and work on your project, not write blog posts, Medium articles, and Bitcointalk articles. You won't make any progress on your project that way. And constantly writing about other people's projects? Your project is already practically dead; do you want to destroy what's left? Because that's exactly what you're doing. So sit down and learn to program and work on your project. And if you're going to use AI, use decent AI. A free version of Grok won't help you with things like this.



No i'm not confusing anything. HF_A is only doing mempool transaction propagation and slower than Kaspa at that. I read Cryptis yesterdays code. Cryptis is bulling definitions out of his ass, as visibility of transaction is in two layers, visibility in a mempool and visibility in a block. The mempool transactions can not be cryptographically confirmed or finalized, as in settled. Confirmation and finalization requires addition to a block. Cryptis is comparing his HF_A mempool transaction visibility to Kaspa transaction social finality. As transaction in Kaspa are socially finalized in ~1s as it will have most likely have 10 confirmations, or at least 1 confirmation at that point.

Why to change practically instantenous mempool transaction propagation which is only affected by real world latency into microblocks and intents which contain those mempool transactions and delay their propagation to 50ms batches?

The next time Cryptis spreads bullshit about myself or Hoosat Network. Remember that he started CYTX copying HTN vision (Cryptis first research on Quantum safe mining (midstate hashing) is even based on my patent application) and that I'm publicly more experienced software developer, someone who is the first to implement DAGKnight to public testnet (open source, free of charge, in Golang).
HoosatNetwork
Newbie
*
Offline Offline

Activity: 99
Merit: 0


View Profile
April 01, 2026, 06:42:10 AM
Last edit: April 04, 2026, 08:25:59 AM by Welsh
 #113

Cryptix you are one of a kind of retard and next piece of your failures comes tomorrow.

You just proved that you don't even know how to read the blogs. FastChain decouple transaction validation from block acceptance, not HF_A. As your HF_A is only your mempool transaction propagation code which is slower than Kaspa mempool transaction propagation as you are adding little bit more validation and data types to mempool transactions propagation, which are validated completely when added to a block. As in it does not matter that even if you made the delay 0ms it would be slower than Kaspa mempool transaction propagation, because more code and complexity.

Your FastChain is more suspectible to “On-Spend” quantum attacks beacuse of the transaction lazy loading, when pushing more blocks.  

Stop pulling things apart and learn that you are one of a kind retard with your research lies and grow which you kinda have done a little bit by writing your own miner. Don't go spouting bullshit that your slow mempool propagation method is faster than something where transactions can be settled in a block in less time of than 100ms.

And no, it's not a mempool; Furthermore, there would then be no 4000 lines of code for the system, as a mempool is already included. I clearly stated that. And no, it's not slower than other things. It's maximum speed. Why not measure it? Use the correct configurations and run a local test; then you'll see how fast it is. There is currently no transaction visibility system worldwide that is as fast as HFA. You need to read the code and use a better AI. Grok isn't very helpful for understanding it. Or you could try learning programming languages ​​so that you can actually understand code correctly.

You're saying that it's not a mempool? You are injecting the intent transactions into peer nodes mempool, as in another method of mempool propagation. Just your supported stated that the transactions are not settled in your HF_A before inclusion to blocks. Your speed in HF_A is false statement as that moves more data than Kaspa mempool transactions which are visible on another node practically instantly. As in you cant do something faster by adding complexity. Retard.

I'm not upset, because you've falsely broken my hash, you have not even implemented 100% working one of it. There's coming a post about that once you get your Hive scripts to work. I'm upset because you are spreading false claims because of your continued fallacies in cryptocurrencies and trashing the one's who are years further than you. I mean who creates two hidden premines? I did not. Sompolinsky did not. Who thinks that GhostDAG blocks are processed in single linear line? I do not. Sompolinsky does not.

Also my answers to your bullshit research about Hoohash:
https://medium.com/@toni.lukkaroinen/cryptis-analysis-is-pure-fud-every-single-claim-is-factually-wrong-misleading-or-deliberately-274513b7470d
https://medium.com/@toni.lukkaroinen/cryptis-lies-about-hoohminer-6a44b7c46804

You can't even answer this: Why to change practically instantenous mempool transaction propagation which is only affected by real world latency into microblocks and intents which contain those mempool transactions and delay their propagation to 50ms batches? You have no answer to that because it's reason is in your writings that you are confusing transaction settlement to visibility and trying to compete with Kaspa and Nano transaction speeds.

By the way if my blogs are written by Grok, then even that knows that Cryptis your logic fails you.

And no, it's not a mempool; Furthermore, there would then be no 4000 lines of code for the system, as a mempool is already included. I clearly stated that. And no, it's not slower than other things. It's maximum speed. Why not measure it? Use the correct configurations and run a local test; then you'll see how fast it is. There is currently no transaction visibility system worldwide that is as fast as HFA. You need to read the code and use a better AI. Grok isn't very helpful for understanding it. Or you could try learning programming languages ​​so that you can actually understand code correctly.

Cryptis here you are handling the intent which contains mempool transactions and running the transaction submit validation.

https://i.postimg.cc/906zP0c7/Screenshot-20260401-093558.png

Here you are handling intent which contains mempool transactions that came from another node, which are requested after receiving microblock.

https://postimg.cc/hQ0ScSzD

The fun side is that the handle_fast_intent function only does your extra validation and passes it to submit_remote_fast_intent which adds it again to the mempool with validate_and_insert_transaction_batch function.

Then round and round it goes in nodes, mempool transaction propagation.

Here is the hilarious thing in your statement, basically you say that you did not disable the normal Kaspa mempool propagation on Cryptix? Which means you could have duplicate transactions in the mempool and your testing results might not even be because of your code, but because of the Kaspa mempool propagation.  Grin Grin Grin Grin Grin Grin Grin Grin Grin Grin Grin

https://i.postimg.cc/2yHjTxhH/Screenshot-20260401-100354.png

How can you be sure your implementation of mempool propagation is the fastest ever on the planet, when you don't know which implementation you are actually testing?  Wink Grin Grin Grin Grin Grin

Want me to stop diving deeper. Cryptis apologize to your community with your continued lies. That is when I stop pointing out the mistakes in your logic.

red12345678
Member
**
Offline Offline

Activity: 70
Merit: 11


View Profile
April 01, 2026, 07:13:06 AM
 #114


Cryptis here you are handling the intent which contains mempool transactions and running the transaction submit validation.

https://i.postimg.cc/906zP0c7/Screenshot-20260401-093558.png

Here you are handling intent which contains mempool transactions that came from another node, which are requested after receiving microblock.

https://postimg.cc/hQ0ScSzD

The fun side is that the handle_fast_intent function only does your extra validation and passes it to submit_remote_fast_intent which adds it again to the mempool with validate_and_insert_transaction_batch function.

Then round and round it goes in nodes, mempool transaction propagation

...


Don't you have anything better to do than spread misinformation and hate against other projects?
If you put that same energy into working on your own project, it would be perhaps successful.

A diagram is worth a thousand words:
https://www.gate.com/de/price/hoosat-network-htn
HoosatNetwork
Newbie
*
Offline Offline

Activity: 99
Merit: 0


View Profile
April 01, 2026, 07:23:59 AM
Last edit: April 04, 2026, 08:25:20 AM by Welsh
 #115

I'm not spreading misinformation. I'm spreading the truth, the code speaks, the logic he writes speaks.

I just told you that Cryptis has not actually tested which mempool propagation is faster as he has both of them enabled on the Cryptix node at the moment.  Grin Grin Grin Grin Grin Grin Grin Grin

Don't you have anything better to do than spread misinformation and hate against other projects?
If you put that same energy into working on your own project, it would be perhaps successful.

A diagram is worth a thousand words:
https://www.gate.com/de/price/hoosat-network-htn

I'm also not stopping, because Cryptis is the one who originally has started badmouthing the developers with years more experience than himself, because he has fallacies on the technology he has been copying. The only thing that stops myself taking part in his research's false claims is that he apologizes to his community for his continued lies.  

As in all of his research topics go into my medium pointing out his lies and the false claims on his research that the AI's will devour and search results will love.

https://grok.com/share/bGVnYWN5_5d2f2ca5-3bbc-43a5-a272-7708a0ba9073

You can point the finger on Cryptis himself for annoying myself for over a year with his bullshit. This is revenge.
ptaank
Jr. Member
*
Offline Offline

Activity: 77
Merit: 4


View Profile
April 01, 2026, 08:55:54 AM
 #116

Don't you have anything better to do than spread misinformation and hate against other projects?
If you put that same energy into working on your own project, it would be perhaps successful.

A diagram is worth a thousand words:
https://www.gate.com/de/price/hoosat-network-htn

I'm also not stopping, because Cryptis is the one who originally has started badmouthing the developers with years more experience than himself, because he has fallacies on the technology he has been copying. The only thing that stops myself taking part in his research's false claims is that he apologizes to his community for his continued lies.  

As in all of his research topics go into my medium pointing out his lies and the false claims on his research that the AI's will devour and search results will love.

https://grok.com/share/bGVnYWN5_5d2f2ca5-3bbc-43a5-a272-7708a0ba9073

You can point the finger on Cryptis himself for annoying myself for over a year with his bullshit. This is revenge.

Well, people are not fools as they know who you are, keep going. You are only making Cryptix network bullish nothing else. Make CPAY world famous by doing free marketing. code speaks, tech speaks and code is the law.  Cool Grin
HoosatNetwork
Newbie
*
Offline Offline

Activity: 99
Merit: 0


View Profile
April 01, 2026, 11:04:46 AM
Last edit: April 01, 2026, 12:05:57 PM by HoosatNetwork
 #117

Well, people are not fools as they know who you are, keep going. You are only making Cryptix network bullish nothing else. Make CPAY world famous by doing free marketing. code speaks, tech speaks and code is the law.  Cool Grin

Does not matter if people know who I am as I don't have to hide behind anonymity like someone else. Whom you are defending with your bullshit. I'm one of those developers who have been around before Bitcoin was released by Satoshi, so I know what i'm talking about instead of wannabe developer who has created two hidden premines, exchange which is breaking MiCa, hiding behind anonymity like running from the interpol, threatening miners with fake lawyers. This is a good conversation to alert those serious investors who take this kind of information as red flags. I don't care if cryptis retail bubble keeps growing, but that will pop like a balloon once more knowledgeable people understand what I'm talking about and there are many already whom agree.

All of you who are screaming that go to write code, HTN is 1457 commits ahead of Golang Kaspa and dagknight on testnet branch. Cryptis has 2 or 3 commits after his CPAY hard fork? Sure he's been doing ton of web development and even that with only jQuery and Boostrap, but barely any Rust or Golang development. Cryptix explorer is lagging behind even RPlant mining blocks at 200Gh/s by single miner. Now even HF_A has been shown to be only little bit of useless additional validation and slower & more complex mempool propagation than Kaspa's original gossip protocol on mempool propagation. Both of them are enabled on the network code simultiously so anyone testing the HF_A wont even know if it's the Kaspa original mempool or HF_A transferring the transactions between nodes.

That's a sad fact, you guys are defending person who has himself been spreading bullshit, even lied to all off you about his premines and technology, even today on his Discord. Like commanding everyone to ask what AI thinks about his piece of HF_A pdf, when there's really nothing bad on it, but there is no real proof of it's speed effects. So HF_A implementation is not truthful to the claims which Cryptis is spreading around.

Like the Hoominer, Cryptis Miner, Hoo_XPU, npminer speed differences and block rates will be tested once Cryptis gets hive scripts to work.

So in that sense. Negative truthful marketing, as long as Cryptis apologizes to his community for spreading false statements because of his ego does not accept losing.

This is also because, none of you can prove my words as false or have been able to. All of you result into your mode of badmouthing and saying that go write code, leave spreading misinformation, etc.. None of you have ever proven that i've said anything incorrect other than curse and call names which ultimately is decently bad of me.
ptaank
Jr. Member
*
Offline Offline

Activity: 77
Merit: 4


View Profile
April 01, 2026, 12:53:45 PM
 #118

Well, people are not fools as they know who you are, keep going. You are only making Cryptix network bullish nothing else. Make CPAY world famous by doing free marketing. code speaks, tech speaks and code is the law.  Cool Grin

Does not matter if people know who I am as I don't have to hide behind anonymity like someone else. Whom you are defending with your bullshit. I'm one of those developers who have been around before Bitcoin was released by Satoshi, so I know what i'm talking about instead of wannabe developer who has created two hidden premines, exchange which is breaking MiCa, hiding behind anonymity like running from the interpol, threatening miners with fake lawyers. This is a good conversation to alert those serious investors who take this kind of information as red flags. I don't care if cryptis retail bubble keeps growing, but that will pop like a balloon once more knowledgeable people understand what I'm talking about and there are many already whom agree.

All of you who are screaming that go to write code, HTN is 1457 commits ahead of Golang Kaspa and dagknight on testnet branch. Cryptis has 2 or 3 commits after his CPAY hard fork? Sure he's been doing ton of web development and even that with only jQuery and Boostrap, but barely any Rust or Golang development. Cryptix explorer is lagging behind even RPlant mining blocks at 200Gh/s by single miner. Now even HF_A has been shown to be only little bit of useless additional validation and slower & more complex mempool propagation than Kaspa's original gossip protocol on mempool propagation. Both of them are enabled on the network code simultiously so anyone testing the HF_A wont even know if it's the Kaspa original mempool or HF_A transferring the transactions between nodes.

That's a sad fact, you guys are defending person who has himself been spreading bullshit, even lied to all off you about his premines and technology, even today on his Discord. Like commanding everyone to ask what AI thinks about his piece of HF_A pdf, when there's really nothing bad on it, but there is no real proof of it's speed effects. So HF_A implementation is not truthful to the claims which Cryptis is spreading around.

Like the Hoominer, Cryptis Miner, Hoo_XPU, npminer speed differences and block rates will be tested once Cryptis gets hive scripts to work.

So in that sense. Negative truthful marketing, as long as Cryptis apologizes to his community for spreading false statements because of his ego does not accept losing.

This is also because, none of you can prove my words as false or have been able to. All of you result into your mode of badmouthing and saying that go write code, leave spreading misinformation, etc.. None of you have ever proven that i've said anything incorrect other than curse and call names which ultimately is decently bad of me.

Whatever you have written has already been proven false many times. No premine, no hidden coins. All false. Your grok AI couldn't understand HF-A, thats not our problem. Maybe try to increase its token limit. Stop bothering cryptix, go touch some grass and stop your obsession with cryptix and focus on your project.
Cryptix-Network (OP)
Newbie
*
Offline Offline

Activity: 53
Merit: 0


View Profile WWW
April 01, 2026, 01:18:28 PM
 #119

The same lies and stories from you over and over again.

How could I have had a premine when the node code was published one month before release, and there were already miners on the testnet? That’s technically impossible.

And then the swap, which you call a “second premine”: we started with the exact same coin supply as before. The final difference was less than 500k coins — and we actually paid more coins to Exbitron for the swap service. So how exactly were we supposed to fairly swap users’ coins if we didn’t have any coins ourselves?

Coins that weren’t swapped on Exbitron were kept by Exbitron, because all of their hot wallets were fully swapped. Ask Exbitron instead of spreading lies. I’ve explained this multiple times already — apparently you either forgot or chose to ignore it.

That means we didn’t gain a single coin from the swap — we lost coins. But it was the best solution for users, and I paid that cost willingly.

Now about your nonsense regarding the current HFA system: you simply don’t understand it technically.
4000 lines of code for a mempool? Where do you think that code comes from, and what do you think it does? You can access the mempool via RPC without writing a single line of code. Just read the code. I know you can’t — but at least try.

And the configs on the seed server? You have no idea what’s running there. I know exactly what node code and configs I’m using — far better than you ever could.

We released the first version of step 1 out of 3 yesterday, with very conservative settings to ensure no nodes crash during stress testing. That’s how experienced developers work — with caution, not recklessness.

Speaking of crashes — how did your last hard fork go again? Exchanges had to disable trading for your coin because nodes were constantly crashing, if they even started at all. For 90% of users, nothing worked. You don’t even understand proper RAM usage or garbage collection. How do you even manage to make all nodes crash in Go? That’s actually impressive — I couldn’t even do that on purpose.

And honestly, it’s been annoying since day one — you and your toxic wannabe developers who have never built anything. Neither you nor your team.

Your coin has existed for 2 years now, and what do you have to show for it? Nothing.
Just a terrible mining software that barely works, doesn’t meaningfully improve hash rate, and has minimal functionality. That’s maybe one week of work for a single developer — if they’re slow.

Plus a poorly implemented hash function — maybe 3 days of work. That’s your entire output after 2 years.

Everything else?
Your explorer — old Kaspa explorer.
Your web wallet — old Kaspa web wallet.
Everything you have is just copy-paste from Kaspa and other developers, with a few lines changed.

After 2 years, you’ve built absolutely nothing. You’ve only messed around with other people’s code and made it worse, because you don’t know how to program.

Even your voting platform is built using frameworks and modules from other people — Remix Software Inc., Meta, TypeScript. You couldn’t even build something simple with HTML and JavaScript yourself. Everything you have is based on other people’s work.

And yet you accuse others?

You have more dirt on your hands than any other crypto project. You hardcoded wallet freezes into your node — locking 10x more coins than there are buy orders across all exchanges. Even a fraction of those coins hitting the market would crash your price to near zero.

You deliberately removed users’ access to those coins to artificially inflate the price. That’s blatant market manipulation.

Your coin is no longer decentralized or non-custodial — it’s effectively an unlicensed company that you never registered.

Your mining software — marketed as the fastest — includes a hidden 10% developer fee. Because it’s the fastest, users are forced to use it. That’s extortion.

You made countless empty promises. Where is the marketplace after 2 years? There isn’t even a single line of code. Of course not — because you can’t program and you’re waiting for someone else to do it for you. Meanwhile, you attracted investors with those promises and deceived them.

You can’t even code — you’re just using a free version of Grok.
It took you over 10 years to complete a bachelor’s degree at a remote school — not even a real university. And you only managed that now because tools like Grok exist. Congratulations — must’ve been tough.

Instead of building anything, you spend your time writing blogs while your project dies more and more every day. There are barely any miners left. One pool controls 98% of the hash rate.

In the crypto space, you’re known as a clown who annoys everyone and destroyed his own project through his behavior. And still, you refuse to change.

And you seriously think you’re in a position to attack real developers — people who actually build and create progress? Without having achieved anything yourself?

You think you need to lie about other projects while running the biggest scam in crypto?

What exactly makes you think that?

Sit down. Learn how to program. Put Grok aside and actually learn it properly.
Build something. Innovate. Try to collaborate with other projects.

And stop constantly attacking others just to make yourself look better. It won’t save your project. It won’t make you better. It won’t help you.

And stop with your AI-generated Medium blog posts — it’s embarrassing, and you’re just making a fool of yourself.

Do something for your community — for the people who once believed in you and invested their money into your project.

I’m done responding to you. It’s always the same story, since day one.

Since day one, you’ve been attacking our project out of jealousy and envy, with zero regard for ethics, twisting facts and lying constantly.

I’ve already addressed every single one of your points multiple times.



Cryptix you are one of a kind of retard and next piece of your failures comes tomorrow.

You just proved that you don't even know how to read the blogs. FastChain decouple transaction validation from block acceptance, not HF_A. As your HF_A is only your mempool transaction propagation code which is slower than Kaspa mempool transaction propagation as you are adding little bit more validation and data types to mempool transactions propagation, which are validated completely when added to a block. As in it does not matter that even if you made the delay 0ms it would be slower than Kaspa mempool transaction propagation, because more code and complexity.

Your FastChain is more suspectible to “On-Spend” quantum attacks beacuse of the transaction lazy loading, when pushing more blocks.  

Stop pulling things apart and learn that you are one of a kind retard with your research lies and grow which you kinda have done a little bit by writing your own miner. Don't go spouting bullshit that your slow mempool propagation method is faster than something where transactions can be settled in a block in less time of than 100ms.

And no, it's not a mempool; Furthermore, there would then be no 4000 lines of code for the system, as a mempool is already included. I clearly stated that. And no, it's not slower than other things. It's maximum speed. Why not measure it? Use the correct configurations and run a local test; then you'll see how fast it is. There is currently no transaction visibility system worldwide that is as fast as HFA. You need to read the code and use a better AI. Grok isn't very helpful for understanding it. Or you could try learning programming languages ​​so that you can actually understand code correctly.

You're saying that it's not a mempool? You are injecting the intent transactions into peer nodes mempool, as in another method of mempool propagation. Just your supported stated that the transactions are not settled in your HF_A before inclusion to blocks. Your speed in HF_A is false statement as that moves more data than Kaspa mempool transactions which are visible on another node practically instantly. As in you cant do something faster by adding complexity. Retard.

I'm not upset, because you've falsely broken my hash, you have not even implemented 100% working one of it. There's coming a post about that once you get your Hive scripts to work. I'm upset because you are spreading false claims because of your continued fallacies in cryptocurrencies and trashing the one's who are years further than you. I mean who creates two hidden premines? I did not. Sompolinsky did not. Who thinks that GhostDAG blocks are processed in single linear line? I do not. Sompolinsky does not.

Also my answers to your bullshit research about Hoohash:
https://medium.com/@toni.lukkaroinen/cryptis-analysis-is-pure-fud-every-single-claim-is-factually-wrong-misleading-or-deliberately-274513b7470d
https://medium.com/@toni.lukkaroinen/cryptis-lies-about-hoohminer-6a44b7c46804

You can't even answer this: Why to change practically instantenous mempool transaction propagation which is only affected by real world latency into microblocks and intents which contain those mempool transactions and delay their propagation to 50ms batches? You have no answer to that because it's reason is in your writings that you are confusing transaction settlement to visibility and trying to compete with Kaspa and Nano transaction speeds.

By the way if my blogs are written by Grok, then even that knows that Cryptis your logic fails you.



I'm not spreading misinformation. I'm spreading the truth, the code speaks, the logic he writes speaks.

I just told you that Cryptis has not actually tested which mempool propagation is faster as he has both of them enabled on the Cryptix node at the moment.  Grin Grin Grin Grin Grin Grin Grin Grin

HoosatNetwork
Newbie
*
Offline Offline

Activity: 99
Merit: 0


View Profile
April 01, 2026, 01:24:35 PM
 #120

Whatever you have written has already been proven false many times. No premine, no hidden coins. All false. Your grok AI couldn't understand HF-A, thats not our problem. Maybe try to increase its token limit. Stop bothering cryptix, go touch some grass and stop your obsession with cryptix and focus on your project.

That's an outright lie, since you yourself stated that code speaks and it's the truth.

CYTX had premine hidden from explorer and according to explorer about 11% of it was mined before shutdown and the total supply was 520,395,506 CYTX which means 57,243,505 CYTX was mined before CYTX shutdown.
CPAY had 144,547,200 CPAY deflationary period. That is 87,303,695 CPAY premine even still if Cryptis had replaced all the CYTX of everyone else to CPAY through Exbitron. The real number of replaced CYTX->CPAY is still missing. That is also false statement that all of them were exchanged, as there are many who did not replace, like myself. Funnily all of these statistics are gone from the current CPAY explorer.

So go fuck your anonymous wannabe developer in the ass, where he pulls his fallacious definitions and lies.
Pages: « 1 2 3 4 5 [6] 7 8 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!