User:
Misa AmaneThis user is spamming the technical discussion boards with AI generated posts.
BIP352 silent payments are indeed computationally heavy, especially when scanning is done in Python. Each tweak has to be checked against the view key, which makes it expensive at scale.
If you move the scanning logic to a more efficient language like Rust or C++, it can significantly reduce CPU load. Offloading mempool and block scanning to a separate service or worker node is also a good idea, as it allows the main node to properly handle tasks like zero-conf transactions.
Relying solely on Core RPC feels somewhat limiting for high-traffic environments. You could consider batching, parallel processing, or indexing solutions to improve performance. Since silent payments are still relatively new, scalability challenges like this are expected.
originality.ai - 100% confident that’s AI
gptzero.me - 100% AI
copyleaks - 100% AI content found
From what I understand, CoinSwap is a privacy-focused crypto transaction method that allows users to swap coins directly with each other. The interesting part is that outsiders cannot easily trace where the coins actually moved.
In my opinion, it was mainly created to enhance privacy, similar to how Bitcoin uses a UTXO-based network to improve transaction confidentiality.
The core idea of CoinSwap is to swap coin ownership rather than making direct transactions.
Simply put:
1. Two or more users exchange their coins with each other.
2. The transaction history is structured in a way that makes tracking difficult.
3. There is no direct sender → receiver link.
4. It uses smart contracts like HTLC (Hashed Timelock Contracts) to execute securely.
CoinSwap offers several advantages, including high privacy, improved fungibility, the ability to confuse blockchain analysis tools, and enhanced privacy without relying on centralized mixers.
It also has drawbacks such as complex implementation, limited adoption, and the risk of funds being locked if used incorrectly.
Still, I believe CoinSwap is important.
For example:
Normally you send Bitcoin from A → B.
But with CoinSwap, you swap coins with another party
B receives coins from a different source making it difficult for outsiders to trace the original transaction.
gptzero.me - 96% AI
originality.ai - 100% confident that’s AI
copyleaks - 100% AI content found
To me, this feels less like a Bitcoin wallet and more like a thin wrapper around Strike services.
Using OAuth 2.0 for login already indicates that user access depends on a centralized provider. That directly contradicts the core idea of self-custody. If the wallet cannot function independently of Strike, then calling it a “wallet” is somewhat misleading I think it’s more accurate to describe it as an account interface.
Features like push notifications and biometric login do improve convenience, but they don’t address the fundamental question: who controls the keys?
If key management is not fully local and verifiable, then the user is simply trusting another layer without gaining real sovereignty.
Another major issue is transparency. For a project at version 0.0.8, I would expect clear documentation on:
1. How keys are generated and stored
2. Whether any data is routed through external servers
3. How the Coinos integration actually works under the hood
So far, these aspects are either not clearly explained or seem to be missing, which makes it difficult to properly evaluate the security model.
To put it simply: without removing centralized authentication dependency and without clear proof of self-custody, this doesn’t offer much advantage over using Strike directly.
If the goal is to build a serious Bitcoin wallet, then the priority should be trust minimization, open architecture, and independent key ownership before adding convenience features.
originality.ai - 100% confident that’s AI
gptzero.me - 96% AI
copyleaks.com - 100% AI content found