Safecoin computational/communication density

Autonomi Network Token (incl (e)MAID)
1

Per the Safecoin paper (and elsewhere), each safecoin has its own unique ID and transaction of that safecoin is verified by a Transaction Manager group with a near ID to the safecoin ID. This will also have to apply to any subdivisions of safecoin when this facility is added to the network.

My question and concern has to do with the amount of action that will have to go on behind the scenes for every safecoin transaction, especially for a large quantity of safecoin and/or conglomerations of a lot of smaller units as the denomination of safecoin becomes fractionalized.

As I understand this, if I send three safecoin to someone, it will require consulting as many as three Transaction Manager groups to confirm the transaction. If those three safecoins are made up of an amalgamation of previously divided safecoin (of, say, 1/100th sc units) that same transaction could potentially require consultation of as many as 300 Transaction Manager groups to confirm the same transaction.

I know an awful lot of computation can happen very fast, but this also requires a lot of inter-node communication.

I can see this as an attack vector, but also am trying to wrap my head around the amount of computation and action that will be required for safecoin transactions, especially as safecoin become subdivided.

So, my question is: How much of a concern is this actually? I don’t mean to make undue distraction for you, @dirvine, but I’m sure you’ve thought on this and hope you can reassure without too much distraction.

5 Likes
2

I have the same concern month ago, specially about the possibility of spam transaction or spam division.

3

This is not unique to subdivisions, this inefficiency will exist from the beginning. It’s not uncommon for early adopters to have tens or hundreds of thousands, some even millions of SafeCoins. Imagine deciding to transfer such numbers to another account.

If this turns out to be a major scalability problem, it might be an idea to look into grouping SafeCoins where grouped SafeCoins inherit ownership of the group. For example:

An account’s SafeCoins could always be organized in such a way that there is always one SafeCoin group for every order of ten. For example, if you own 38021 SafeCoins they would be grouped like this:

ungrouped 1
2 groups of 10
10 groups of 100
7 groups of 1000
3 groups of 10000

Now if you want to send 2492 SafeCoins to someone, you would have the following transactions:

2 loose SafeCoins (only 1 loose available, so break up 1 group of 10. This means 10 extra transactions to break up the group)
9 groups of 10 (8 groups too short, so we need to break up a group of 100 into 10 groups of 10. That’s 100 extra transactions)
4 groups of 100 (6 groups left)
2 groups of 1000 (5 groups left)

Total transactions: 2 + 10 + 9 + 100 + 4 + 2 = 127 transactions to send 2492 SafeCoins.

For subdivisions the same mechanism can apply for fractions of 10.

This would of course all be done under the hood without the user’s awareness. Note that a SafeCoin group could actually be represented by a single SafeCoin, to which the other SafeCoins of that group are linked to inherit it’s ownership. I.e. the representative SafeCoin’s ID is the ownerID in all the other SafeCoins of that group.

1 Like
4

I’m waiting to hear from he-who-is-in-the-know before I speculate.

5

Worst case, still no parallel to block chain level of in efficiency?

2 Likes
6

It is a lot and this is why sub divisions should only happen will after launch and the network grows. Then its simpler. The tx manager groups are distributed across the address range evenly so if you had a million exchanges it is likely on a million groups and each group will do very little (signature check). This is one of the hard things to see, but the number of the computations is large but so is the number of groups doing it (like ultra core computing). So early on when the network is small this is an issue but as it grows then less so.

3 Likes
7

Thanks, David. I knew you’d be able to give just the right data and perspective. :smiley:

8

My thoughts…

If the fiat value goes lower, we will have prices ranging in thousands of Safecoin or more. Bring a bag of pennies to pay for a groceries. If the fiat value goes higher, we will need subdivision to for smaller transactions. Buy coffee with a gold coin.

No matter what happens, there will be different price tiers. If Safecoin is to become a fully functional currency, it must have flexibility.

I think Bitcoin implemented transaction costs for this reason. Even without subdivisions, a malicious user with millions of Safecoin could transfer back and forth between two accounts. This could be problematic. I recommend testing this attack vector on testnet3.

Solution?
Since we don’t want transaction costs, we must find a way to minimize the workload for large transactions.

@Seneca offered a group ownership solution above.

If possible, I think automatic tier conversion by the transaction manager could mitigate this problem. I would make it convert every 1,000 Safecoins… 1,000,000… 1,000,000,000… etc.

Why not every 100 or 10?
Because, those 100 or 10 will likely be broken down again, causing more work for the Network.

Sending 2,492 Safecoins will break down as follows.
2 Transactions x(1000) Safecoins
492 Transactions x(1) Safecoins

The receiving user doesn’t see the break down. They only see their 2,492 Safecoin balance.
But from a Network standpoint, we saved a lot of work.

I’m sure we will come up with a more elegant solution.

EDIT: We have a future solution planned :smile:

9

I think introducing transaction costs is a bad solution to the problem, in the same order as DRM being a bad solution to piracy. You hurt all your legitimate users as well.

When transferring SafeCoins, the previous_owner needs to sign every SafeCoin’s new current_owner field. What about making this become quite a burden in the case of spam, by making the signing computationally heavier?

Also, I think it must be possible to make a spammer’s manager group punish or temporarily ignore the spammer. All that’s needed is a clear rule on what constitutes spam transactions and legitimate transactions, so the manager group can form consensus on whether to ignore or even blacklist that user.

1 Like
10

Or allow transaction manager’s to postpone a transaction if that SafeCoin was just transacted already, for 30 seconds for example?

Such rules do not get in the way of most legitimate use, but do they combat spam. The lack of transaction costs is one of the awesome potential features of SafeCoin, it should in my opinion be a measure of very last resort.

2 Likes
11

Maybe the excerpt from a mail I typed the other day will help.

struct safecoin {
std::vector<PublicIdHash> current_owners; // this gives us multisig as coins only release to new owner when >= majority of current owners sign
std::vector<PublicIdHash> previous_owners;
std::vector<signatures> signatures; // signatures of previous owners (who have actually signed the new owners are valid (they sign coinid+new_owners)
}

So only signed id’s can sign the coin over to the new owner. (the signed Id in this case is the current owner who can replace the previous owners signatures), I have shown the struct like this for simplicity, but essentially you do not need to keep the older signatures (it’s for show here) V1.0 will possibly maintain the signatures as it adds another layer of checking for now (overly pedantic with security)

Looking at the coin you an get the previous owners id → retrieve their public key and confirm the current owner has been signed by previous owner(s).
The transaction managers will accept a message signed by the new owner (by retrieving the public key and confirm signed request) to transfer ownership to new owner(s). We may test not keeping the signature but the public keys, so you can replace sign+prev owner with a vector of public keys (it’s faster) but has potential drawbacks.
If the coin has not finished being transferred (in a multisig) any previous owner can withdraw their signature to sign over (for contracts that break down etc.). Limbo coins will not be able to be transferred (by default they are locked with the algorithm itself, not physically)

There is an opportunity to replace all of this with integers alone, so the ints would be 64 bit and it is a case of transferring a number which is way more efficient, but we are still analysing the implications right now. If a single group were compromised with the second scheme then it would mean all coins in trouble. In the initial scheme then only a members coins could get into trouble (very limited even at that). At the moment any compromised group (yes if somebody did join over time with 3 times the network size or more) then it is a DOS type attack or vandalism and not theft. So its good to keep that paradigm in place.

So the in future will be possible to switch to the int value alone, then subdivision is instant and super super simple, We jut probably need the balance of slow and steady → high efficiency.

Switching to such a scheme could easily be done in real time with the clients all converting old safecoin to new safecoin (everyone’s client would automatically do this if we decided on this action). So it would be painless but a version number upgrade for sure. Its a reason I am not too worried about subdivision and workload, the answer as ever will be fundamental and more efficient again.

In terms of the vandalism or traffic attack described then it is on the attacker to sign the transaction (which is computationally more heavy that checking) so the way to defeat this kind of DOS thing (or traffic amplification attack) is to make it cheap for the network and expensive for the attacker. I think we are OK there.

6 Likes
12

Agreed,

I only pointed out Bitcoin transaction costs to show they recognized the problem. But I don’t advocate transaction costs.

We have to be careful how we judge spammers. There are people who transact in very large amounts, and frequently move money (Safecoins) between different accounts. As a business background, this is very common, for example sending money to your payroll account once you issue out paychecks. Or sending it to a purchasing account… etc.

Hopefully we’ll come up with something very practical that works.

4 Likes
13

Bitcoin transactions have a certain real cost too - not only do they require confirmation, but they also consume storage space in the blockchain forever.

Confirmations in Bitcoin are expensive as the whole network needs to reach a majority consensus. Blockchain storage is expensive as every node must store the transaction.

In contrast, Safecoin has a small group of nodes to confirm the transaction and no storage requirements for journaling the transaction details.

Therefore, there is a far smaller (many orders of magnitude) at-transaction time computational cost and no persistent storage cost.

Blockchains are inherently much more costly to maintain and I suspect fees are both critical and unavoidable. As long as Safecoin transaction resource costs are one-off and smaller than the client - entirely feasible it seems - then there would be no need for fees.

2 Likes
14

Ofc, storing and de-duplicating the blockchain on the safe net will reduce Bitcoin overheads and improve blockchain scalability. Safe net wins both ways! :slight_smile:

1 Like