If a Safecoin transaction will be a post then what stops someone from clogging up the network by sending transaction back and forth between many wallets?
Will there be a small transaction fee?
2 Likes
I think it should. Actually, any action that requires a change in the network should require a small fee to reduce abuse, I think anyway, but maybe they have other plans to counter that.
3 Likes
My understanding is that there will be no transaction fee, but there will be limits per client on the number of transactions that can be issued in a given time period. I don’t think the exact nature of those limits has been specified.
5 Likes
This will be what testSAFEcoin needs to test. And I’m sure someone will write a simple script to do just that.
As @sfultong says there is a limit to the speed that transactions can be done because of the verifications being done. This won’t mean the network can only handle coin transactions at this speed like a blockchain, just each transaction will take a finite time with the messages etc back and forth between groups to ensure atomic operation, but network can be performing multiple coin transactions at once.
One of the founding aspects of SAFEcoin was the transaction would always be free. Also initially without division what would the fee be? One SAFEcoin? Multiple “PUT” charges?
Your point though is very much valid and testing will show the reality of what will happen. At least finding out during testing means no coins are lost and no urgent update needed if a “PUT” charge is needed.
Interesting chicken-n-egg problem if charge a fee to send (spend) a coin.
BTW during account creation and the requirement for a coin spend to pay for the "PUT"s to write the account data sets. How does that coin get spent since it needs a fee to send it, but you have no account to hold a “PUT” balance and thus cannot pay the fee? Special coding that then can be exploited?
3 Likes
Initially safecoins were planned to be implemented as SDs (with tag 7) which were free to update.
But now SDs have been replaced with MDs which have an update cost. So, if safecoins are stored in MDs every safecoin transactions will have at least this cost, currently paid with PUT balance credits.
2 Likes
David @dirvine has said that COIN transactions will not incur this cost.
6 Likes
Hm.
I of course think it’s appealing with no fee transactions, I just also see the abuse vector. DDoSing by spinning up wallets and let all wallets send minimum possible amount between themselves, i.e to the growing list of wallets the attacker owns.
A limit could be setup, true, but a limit like that is introducing a magic number which limits the use cases of the network to the boundary of our current imagination.
Maybe it’s good enough though, maybe the limit should be for when to incur fees instead of when to not allow more? Because there could be valid use cases which need the volume, and which will have incentives (by having a desired, valid purpose) to pay the fees - in the end paying the fees to protect the network.
3 Likes
This costs.
In any case a couple of wallets is enough.
The problem for the attacker is that they have to wait for the coin to be sent. We say payments are instantaneous but obviously the reality is that it will take a finite time, maybe a few seconds to clear the transaction is more realistic.
If the attacker tries to send the coin on before it has cleared (ie trying to spam the coin) then there is a chance for that coin to be lost as David points out (somewhere). The potential for losing the coin only happens when one tries to spam or attack the network by “double spending quickly”
Now if the attacker has 1 million coins being spent at 3 seconds put transfer, then maximum transaction rate by the attacker is 333,333 transactions per second across a world wide network. Now for a small network (early on) this would result in transfers taking even longer reducing the effects of the attack.
Testing is obviously needed but the delays in doing the transaction make this kind of attack less effective. The same is true for division if my method is adopted as it uses the same basic mechanism for sending.
The ultra important point here is that unlike a blockchain any attack like this doesn’t clog up the whole system, each transaction is its own entity and isn’t being confirmed by energy/processing heavy processes across the whole network, but simply consensus by two or 3 groups.
4 Likes
At this point of development, it’s the client CPU speed - however many transaction signatures their computer can manage (which is actually quite high). The limit is not the network, which can process updates to coin data extremely quickly.
I did a test of this back in the days of Structured Data.
the rate was usually between 120 - 130 updates per second
CPU load across all vaults was negligible.
CPU load on the client was 100% of one core
I don’t have any statement to make on the fee situation or network congestion until there’s more clarity around the actual design and implementation of safecoin. I do think some incentive is needed to mitigate spam, but I consider that to be a general problem, not a safecoin problem.
5 Likes
Did your test require the consensus of 2 groups, pure transactions doesn’t really equate, although it does give hope that even a coin sending spam attack will not clog up the system. There is somewhere a diagram of the data flow need to send a coin. The number of transactions will be slowed by the lag times across the network to have 2 XOR groups attain consensus. Considering the comms lag times between members of a group is significant compared to a local network and then consensus between 2 groups could easily mean more than one second if not 2 or 3 in cases.
3 Likes
No, it was standard SD updates which as far as I know is just one group. So maybe not totally comparable to coin transactions (especially much so now that MD has replaced SD). My main hope was to contrast network load of updates to SD vs upload of chunks in some loose attempt to begin understanding various spam vectors.
Considering safecoin design is still not out (eg will it definitely need consensus from 2 groups?) SD-update-rate was the closest test I could do, and I really just wanted a ballpark idea of the bottlenecks. Consider the test an anecdote rather than hard facts 
2 Likes