Music to my ears 
20 Likes
Pseudonymous. I don’t believe there is any mixing system in place or in-built proxying obfuscation. But there is no blockchain either. Also transactions are local to you and the entity you trade with (XOR-wise), not broadcast globally like with blockchain tech.
So if your account is known/linked to you and there are people watching your transactions (somehow?), then maybe it could be tracked - but really hard. There are other possibilities down the road for independent mixers and the like to make it even harder.
No third-party apps (unless wallet is third party) or escrow, as everything can be in the wallet. Also super fast & convenient. Probably no fees presuming the network doesn’t adopt transaction fees.
11 Likes
so its means maid will be cointain it self decentralized exchange, without fee?
1 Like
Thx 4 the update Maidsafe devs
High tx’s fees will be answered with SAFE tx’s only, which is good. But bad, if you want non-SAFE assets to become DBCs. When you can enumerate your tx’s through fixed fees, it’s more stable, than high and unpredictable fees.
There are more bitcoins on Ethereum than on the lightning network, because Ethereum was moving faster than Bitcoin and people could make some extra with their btc. SAFE tx’s moving faster than Visa or Mastercard and farming can do the trick.
Keep hacking super ants
11 Likes
Would moving to building only the payments network allow you to estimate how long it would take? Or would it still involve research work that would make it difficult to predict?
4 Likes
I don’t think the team will make a prediction on timeframe. They’ve never done so. Even if they did, it would only be a guess.
What we can take from this however is that launch of the payment only network will happen sooner than if they’d aimed to launch everything together.
So it’s exciting I think. We might not be that far off and very possibly could see a payment only network launch this year - fingers crossed.
Of course that’s simply an outsider impression. I don’t work for Maidsafe.
13 Likes
enlighten me please: without transaction fees, what prevents anyone from sending endless tx to themselves with the aim to overwhelm/disrupt the network?
I feel this is a fundamental issue that the design will have to address eventually. There’s a reason that every other cryptocurrency requires fees.
10 Likes
I thought there was a fair bit of work that the client had to do to prep a transaction. If so then this would slow the ability of sending mass transactions right?
Hence there would be a work/reward ratio for an attacker that needs to be past a certain range, such that it’s not worthwhile.
If the attacker has lots of resources though, then I suppose that’s not an issue.
I’ve argued for a transaction fee in the forum lounge before. I think it does make sense for other reasons too.
Presumably this will be divined during testing.
6 Likes
Maybe a kind reminder (with a little update needed ?)
from Safe Network
By running a Node, your computer races to return any data that is requested by its owner. The rewards paid out by the system will be adjusted autonomously according requirements of the Network in order to balance it in such a way that it consistently maintains around 30% of Nodes unused.
This has been asked and I think answered at least in part.
For SNT the fundamentals require no fees unless absolutely necessary and IIRC one mitigation already planned is pushing most of the work for a transaction to the client, then making spamming the same transaction easier to deal with.
If DBC transactions are free for SNT they can be free for other asset types, but they could be charged although that would add complexity which may not be a good idea.
I think the plan stated is to try to avoid fees and use other measures to prevent spamming but this will be something that will be clarified during tests.
10 Likes
Can we add to this work by including some small but annoying PoW to each transaction? Trivial for say 1-5 transactions but significant for say 100 simultaneous transactions.
Is it possible for a node to query the client to ensure it is running the official released code?
6 Likes
I second your concerns.
Everything that is free and connected to something of value, will be abused in any ways possible.
Cost has to be a part of everything connected to value or abuse , manipulation and possible destruction will happen.
Fees should cover the work that the networks needs to do to deliver the service and some profit on that.
If the cost is higher than what a abuser gains that will help mitigate attacks.
3 Likes
It already has to do work to prep the transaction. So seems redundant to add another proof-of work challenge. As for altering the code, the prep work has do be done for the transaction to be processed by the node, so if the code is altered to not do it, then the transaction would fail.
None of this mitigates an attack from a well funded entity though. However there would have to be a really large number of well funded attackers to cause an overload on the network … testing will hopefully validate.
I’m still not averse to a small transaction fee if needed.
edit: lol - I’m done editing Southside 
4 Likes
But does it have to do enough to make it difficult for spammers?
And I know that “difficult” and “enough” are vague here…
Agreed “honeypotting” can only take us so far. It might be far enough
2 Likes
I don’t know - I suppose that the spam rate is relative to the ability of the network to keep apace. So testing should give good evidence here.
If a PoW does need to be added for this I think there is precedent with another crypto years back (edit: “Nano”) that also has a PoW mechanism on the client end. So it’s doable.
3 Likes
GPT4 If I create a payment network without transaction fees, how can I prevent it from being abused or spammed by malicious actors? Give detailed solutions to this problem that are simplex, efficient, and effective.
Creating a payment network without transaction fees can be challenging, but there are ways to prevent it from being abused or spammed by malicious actors. Here are some simplex, efficient, and effective solutions:
- Proof of Work (PoW): Similar to the mechanism used by Bitcoin, require users to solve a cryptographic puzzle to submit a transaction. This way, malicious actors would need to invest computational resources, making it expensive to flood the network with spam.
- Rate-limiting: Implement a rate-limiting system that restricts the number of transactions a user can submit within a specified time period. This would make it more difficult for attackers to spam the network without affecting genuine users.
- Account validation: Require users to verify their accounts using a unique identifier, such as a phone number or email address. This would add an additional layer of security to the network and make it more challenging for spammers to create multiple accounts.
- Reputation system: Implement a reputation system that assigns scores to users based on their transaction history and behavior. Transactions from users with higher reputation scores could be prioritized, while those with lower scores could be subject to additional scrutiny or limitations.
- Adaptive algorithm: Develop an algorithm that monitors the network for unusual transaction patterns and adjusts the difficulty of submitting a transaction accordingly. This would help protect the network from sudden influxes of spam transactions.
- Whitelisting: Allow only pre-approved users or entities to join and transact on the network. This could be done by requiring users to pass KYC (Know Your Customer) and AML (Anti-Money Laundering) checks before they can transact on the platform.
- Transaction throttling: Introduce a system that limits the transaction throughput for each user based on their past transaction history or the age of their account. This would hinder the ability of spammers to overload the network.
- Collaborative filtering: Develop a system that allows users to report and flag suspicious transactions. This information can be used to train a machine learning model to identify and block spam transactions in real-time.
- Proof of Stake (PoS): Require users to hold and lock up a certain amount of the native currency or tokens in order to submit transactions. This would increase the cost of spamming the network and discourage malicious activity.
- Consensus-based validation: Implement a consensus mechanism, such as Practical Byzantine Fault Tolerance (PBFT), that requires validators to agree on the validity of a transaction. This would make it difficult for a single malicious actor to overwhelm the network.
- Proof of Authority (PoA): Appoint a limited number of trusted validators to verify transactions. Validators can be chosen based on their reputation, technical capabilities, or other criteria, making it difficult for spammers to infiltrate the network.
- Deposit-based system: Require users to make a deposit before they can submit transactions. If their transactions are deemed spam or malicious, the deposit can be confiscated, thus discouraging such behavior.
- Time-based transaction limits: Implement a system that limits the number of transactions a user can submit within a sliding time window (e.g., hourly or daily). This would prevent malicious actors from flooding the network with transactions in a short period.
- Challenge-response mechanisms: Require users to complete a challenge (e.g., CAPTCHA or similar) before they can submit a transaction. This would make it more difficult for bots or automated systems to spam the network.
- Peer-to-peer trust networks: Develop a trust-based system where users vouch for the legitimacy of other users’ transactions. This would create a web of trust that makes it harder for malicious actors to operate on the network.
- Multi-factor authentication (MFA): Require users to provide additional authentication methods (e.g., biometrics, OTP, or hardware tokens) when submitting transactions. This would add an extra layer of security and make it more difficult for spammers to abuse the network.
- Blacklisting: Monitor the network for malicious activity and maintain a blacklist of users, IP addresses, or devices that are involved in spamming or abusive transactions. This would prevent repeat offenders from continuing to harm the network.
- Network partitioning: Divide the network into smaller, interconnected sub-networks, with each sub-network responsible for validating its own set of transactions. This would limit the impact of spam or abuse on the overall network.
By implementing one or more of these solutions, you can create a payment network without transaction fees that remains resilient against abuse and spam from malicious actors.
19 Likes
Thank you @Knosis and ChatGPT
Some combination of the above, perhaps where not every chosen mitigation factor is active at any one time, could make for a very robust system indeed at minimal inconvenience to established honest users. However spotting any deviation from the usual patterns from the EHU <–(must add EHU to Glossary) would be required to stop an organised long game from a state-level adversary.
3 Likes
A flash from the past:
9 Likes
How would you improve this process?
To improve the process you described and further enhance its spam prevention capabilities, you can consider the following adjustments and complementary measures:
- Optimize signature aggregation: Investigate more efficient algorithms or protocols to aggregate signatures, reducing the time and computational resources required for clients to create a transaction. This could help maintain the network’s scalability while still retaining a degree of spam protection.
- Batch transactions: Allow clients to send multiple transactions in a single batch, with a single set of aggregated signatures. This could improve the network’s throughput and reduce the per-transaction workload while maintaining some level of spam prevention.
- Dynamic difficulty: Introduce a dynamic difficulty mechanism that adjusts the required number of signatures from Elder clients based on network conditions. For example, if the network detects an unusually high transaction rate, it could temporarily require additional signatures to deter potential spammers.
- Reputation-based validation: Assign reputation scores to clients based on their transaction history and behavior. Require clients with low reputation scores to obtain more signatures from Elder clients, while clients with high reputation scores could be subject to less stringent requirements.
- Time-based signature expiration: Implement a mechanism that causes signatures from Elder clients to expire after a certain period. This would require clients to obtain new signatures periodically, adding an extra layer of protection against spam.
- Integrate a challenge-response mechanism: Require clients to complete a challenge, such as solving a CAPTCHA, before obtaining signatures from Elder clients. This would make it more difficult for automated systems or bots to participate in the transaction process.
- Rate-limiting: Limit the number of transactions a client can initiate within a specific time frame. This can help prevent clients from overwhelming the network with a large number of transactions in a short period.
- Monitoring and anomaly detection: Monitor the network for unusual patterns or signs of abuse, such as sudden spikes in transaction volume or repeated transactions from a single client. Implement a machine learning-based anomaly detection system to identify and flag suspicious behavior, allowing for timely intervention.
By implementing these improvements and complementary measures, you can enhance the spam prevention capabilities of the process while maintaining scalability and efficiency. It’s essential to continuously assess the network’s performance and make adjustments as needed to ensure optimal security and performance.
12 Likes
That’s an impressive list of options!
I guess a very important factor is that the network / nodes are adaptive, and can somehow measure what capacity they have to process transactions & store data, know what the current level of strain on the network / node is, and adjust rationing measures accordingly (e.g. rate limits / turn on or increase fees etc).
Ideally the rationing would be something that incentivises new nodes to join if the network needs more capacity, which would happen with the full data network as storecost would increase, but with payments only it’s hard to see how the incentives will work unless there are fees.
Looking forward to hearing more details as they’re fleshed out.
5 Likes