Fraser's Safecoin Alternative Design (Postponed State)

[Nigel]

@neo

You have to return the amount even if its a little extra network work.

I agree. It has to be dummy proof. SAFE is taking the hassle of security out of the equation for the world at large, why stop at the wallet which is a core feature?

[jlpell]

@anon86652309
Really nice work on the RFC. Regardless of the practical motivations for limiting oneself to a decimal divisibility of 1 nano Safecoin, there is a subtle elegance to your initial inclination of having a population of 2^32 safecoin where each is divisible into 2^32 parts. It’s natural, fractal and fun!

My interpretation of this version of safecoin is similar to what @mav described, with a little different terminology instead of “pigion holes”. Here goes :

I see your RFC as being similar to a situation where at network launch, the network owns 2^32 “purses”, each containing 2^32 “divs” (divisions by 2) = 1 safecoin. (Because people put real coins in a coin purse for safe keeping, but paper ‘bills’ go in a wallet… ) The network will always own its 2^32 original purses and never transfer ownership. Each client/user has ownership of one or more other purses where some or all of the parts/divs are transferred during the initial disbursement of safecoin for MAID, or during a farming request. When a client/user purchases PUTs from the network, they transfer any quantity of safecoin or ‘divs’ back to one of these network purses in order to receive a PUT balance. If they so choose, clients/users may transfer ownership of one of their purses to another user, including all the safecoin and PUT balance stored therein. When the network pays farmers for successful GETs, safecoin is transferred from one of the network purses to the farmer’s purse, albeit at a much more consistent rate due to the divisibility. Thus the total quantity of safecoin (total in all client purses + total in all farmer purses + total in all network purses) is conserved and fixed to a constant 2^32 throughout all time.

Allowing purses owned by the network to contain more than 1 safecoin may offer some coding convenience. However, it is likely that additional load balancing operations to allow the network to transfer parts of safecoin between its own purses in order to average out the div/part counts would be beneficial. It may be good to allow this balancing to occur across sections. (ie. if this_network_purse.safecoins > section.network_purse_average() : send_safecoins_to_all_network_purses(this_network_purse.safecoins / num_network_purses)

Caveat A) It may be necessary to transfer ownership of ~10% of the network purses to individuals during the initial disbursement of safecoin for MAID in order to adhere to crowdsale stipulations at launch. From that point on, the network would never transfer ownership of its remaining purses. This may be seen as a good thing by initial MAID holders since those purses that were initially transferred might be considered to be “special”.

Caveat B) For better load balancing, it may be beneficial for the network to create additional network purses over time. This is analogous to the “brute force” method of divisibility originally described in the SAFE whitepaper. Regardless, the total quantity of safecoin stored would stay fixed, and the network would never transfer ownership of these purses to clients.

Caveat C) If the bankers out there really hate binary divisibility, the next best thing would seem to be the suggestion by @draw of having up to 4 billion parts per safecoin to maximize usability of the u32. In order to regain the same elegance as before, I would say the total number of safecoin should also be 4 billion. From a marketing perspective this may be a bit easier for the layman to think about too. “There are 4 Billion safecoin and each can be divided into 4 Billion parts…” This would require burning about 7% of the total safecoin purses at launch. I don’t see how crowdsale investors would ever complain because this would increase their relative share of the total supply by about 7%. Technically it would fall in line exactly with the crowdsale description, since there “were” 2^32 safecoin but the network needed to destroy all those addresses above the 4 billionth to make the economics easier to market to human users and bankers for launch. Oops, your investment is now worth MORE, sorry.

EDIT : Just realized that I misinterpreted some of your RFC with regard to farming and safecoin balances stored collectively for an entire section. Anyhow, consider the above some food for thought. I suppose it describes somewhat of a hybrid situation between your RFC and the original “safecoin as data object” description.

[neo]

@jlpell

I see your RFC as being similar to a situation where at network launch, the network owns 2^32 “purses”, each containing 2^32 “divs” (divisions by 2) = 1 safecoin. (Because people put real coins in a coin purse for safe keeping, but paper ‘bills’ go in a wallet… )

things changed in @jlpell’s post (see EDIT)

Is this a new version you are suggesting? Fraser’s version doesn’t do that. The coin accounts are set up by the users and can hold any amount of coins. Its pretty certain that there will be relatively few coin addresses compared to your 2^32 purses.

And as far as the binary division, its not my opinion but that of any system of handling finances apart from crypto which people have repetitively shown they cannot understand unless they are computer technically literate. (ie small %age of those alive) And they complain they cannot get the exact amounts.

[jlpell]

See the “EDIT” I added at the bottom of the post. Yes, I read the RFC too fast and misinterpreted some things. Sorry. Maybe some of that description I wrote is beneficial, maybe not. You guys decide.

[neo]

@jlpell

See the “EDIT” I added at the bottom of the post. Yes, I read the RFC too fast and misinterpreted some things. Sorry.

My bad. . . . . . . . . .

[Traktion]

@TylerAbeoJordan

We have a long past thread on this idea of increasing the number of Safecoins. A lot of people weighed in on it and it seems as though people at the time (2014) were against it overall - but more for touchy-feely reasons and not any hard technical or economic reason. I’m personally still for it though. So long as the percentages are the same no one will really care and if it makes Safecoin technically easier to accomplish, then just do it!

There was always a big problem with increasing the supply with the original RFC-0012 though: Having lots of data objects to represent each coin. Storing and especially transferring lots of these would be relatively slow and costly.

This new implementation doesn’t suffer from this same limitation. Therefore, having a larger supply is possible and potentially desirable.

[neo]

@Traktion

This new implementation doesn’t suffer from this same limitation. Therefore, having a larger supply is possible and potentially desirable.

Good point. . . . . . . .

[TylerAbeoJordan]

Would increasing the total, to the point of being able to get rid of fractions, simplify and/or reduce the burden on network resources with Fraser’s design?

I don’t feel it’s a big concern to do such a ‘split’ - keep in mind that companies do this all the time on the stock market - “stock splits”, so providing we use a similar sort of analogy for people, I believe it can easily be accepted.

Stock split

[Traktion]

@TylerAbeoJordan

Would increasing the total, to the point of being able to get rid of fractions, simplify and/or reduce the burden on network resources with Fraser’s design?

This would be my desired approach and I can’t think of any immediate technical issues. As we would be using fixed point maths with or without parts, the difference of having 1x64bit number vs 2x32bit numbers is inconsequential. However, we would be forced to lose precision on parts in order to retain consistent accuracy. Having just 1x64bit number does not suffer from this, as the limit can be as big as is possible, although that may not be useful/desirable as it is a huge number.

Big numbers remain unwieldy, but less so than small decimals. IMO, it remains easier to work with large numbers due to conventions and education.

[neo]

@Traktion

Big numbers remain unwieldy, but less so than small decimals. IMO, it remains easier to work with large numbers due to conventions and education.

If the proposal changed it to a single u64 field and let the UI determine the display formats for the users (best to allow a few selectable options), then the issue of 2^64 - 1 parts or 2^32*10^9 - 1 parts can be decided later on before beta release candidates. And importantly the proposal can continue without specifying if we change away from the original 2^32 or not.

Then maybe we could have a poll as to the naming of the parts or do we just use the single part as the coin unit and the exchange is like 1 MAID == billions of the that unit? Obviously the same ratio of MAID to total coin count as was the original.

If anyone is wondering what fixed point numbers is about, then its just a integer that has the decimal point placed within the number to represent a decimal number.

For example fixed point with 2 decimal places means that

• integer == 1 decimal number == 0.01
• integer == 12345 decimal number == 123.45

And its up to the UI to put the decimal point in when displaying.

[happybeing]

It’s interesting that my first concern on hearing this idea hasn’t come up yet and isn’t in mav’s list. Maybe that means it is ill founded, but here it is again…

What about the effect on the incentive side of attacks? Does this change significantly is my question, and if so, how cool are we with that?

My concern is that a balance based system creates a much larger incentive to control a section in order to manipulate those balances, than a coin = data system, where the amount of coin controlled by a section is limited (but maybe still a big incentive? So I’m not sure how much of a difference this makes).

So the first part is: does this create a significant, or possibly irresistibly large financial incentive (and in consequence political incentive) to control a section, such that even if it is very expensive indeed, attackers will be willing to pay for it (criminals, corrupt mega corporations, or wealthy authoritarian governments)?

And if so what are the mitigations?

• For example, could good sections detect and ostrasise a section that is fiddling the books? And if they did, how could they recover the data of that section?

• Or can we just be confident that no matter how much money somebody throws at this, they can never control a section? I think we would need to be carful about that, but first: is that our strategy?

As I said, here be a can, with “worms” printed on the side!

[neo]

@happybeing

What about the effect on the incentive side of attacks?

That is in the list of @anon86652309’s questions.

Its not dismissed, but rather there have been a couple of suggestions above

@mav

Can rate limiting be used?

I think a fee makes sense but it’s nice to offer free transactions.

@mav

How is spam control affected? Seems the same.

And some more by people above.

My thought above was to basically put a semaphore around a coin address till the transaction completes. This would provide a limit of sorts, but Fraser did not like that idea,

About the only way is to cause some limiting factor around the sending coin account.

Another way could be to make the API work like this

• the APP/wallet/whatever does an API call to encode the transaction
  • verify the receiving ID exists
  • verify coin account has enough coins
  • return serial transaction request and an encrypted hash to the request
• the APP then submits this serialised transaction with the encrypted hash

This would cause each sending to take extra time and slow down the rate spamming can occur

Now another way @anon86652309 new idea) might be to have an “datachain block number” and the coin account cannot send another request till the current “datachain block number” is larger. If this is too long then have the block entry number instead

[neo]

@happybeing

My concern is that a balance based system creates a much larger incentive to control a section in order to manipulate those balances, than a coin = data system, where the amount of coin controlled by a section is limited (but maybe still a big incentive? So I’m not sure how much of a difference this makes).

The section currently controls the coin addresses in its range. Under Fraser’s proposal the section still only controls the same number of coins.

A controlled section can allocate all coins to the attacker for either system.

I guess the difference is if some sections have coin accounts with proportionally higher amounts than others. But the attacker doesn’t choose the section they get to control so is it a problem?

[draw]

A big incentive I see to controlling 1 section is if it would be possible to ‘create/activate’ new Safecoins and transferring the value of these Safecoins to another section. And then repeat this operation so that you can steal much more Safecoins than the section controls.
If you can only steal the Safecoins already present in 1 section once, that is of course also not desirable, but has less impact/incentive. For instance I expect that an increase in value of Safecoin also means more vaults/sections and therefore less Safecoins controlled by 1 section.
I hope this scenario (of reactivating Safecoins in a hacked section) can be prevented. Like if the sections neighbours would be able to check the inflow/outflow of Safecoins to/from that section. If the ‘total farmed’(=total in use Safecoins in a section) decreases by outflow and than increases very quickly by a lot (because they are ‘activated’ again by the cheating section), without corresponding Safecoin inflow and too much to be explained by normal farming.
Of course if somebody controls a section and its 2(?) neighbours, this maybe circumvented. But maybe there is a check of the neighbour’s neighbours etc. possible to prevent this to a certain point?
And it would also be useful when exchanging Safecoins to something else that your’re able to check if not most Safecoins come from the same section…
This explanation above is probably (partly) nonsense because of my lack of understanding, but I hope the general concern of it is somewhat clear.

[TylerAbeoJordan]

@neo

If anyone is wondering what fixed point numbers is about, then its just a integer that has the decimal point placed within the number to represent a decimal number.

For example fixed point with 2 decimal places means that

• integer == 1 decimal number == 0.01
• integer == 12345 decimal number == 123.45

And its up to the UI to put the decimal point in when displaying.

wow … that is a neat solution. It appears so obvious … in hindsight.

[happybeing]

@neo

The section currently controls the coin addresses in its range. Under Fraser’s proposal the section still only controls the same number of coins.

The attack I envisage is falsifying wallet balances (or transactions). How would a bad section be prevented from ignoring its aggregated coin limit?

I asked if other sections could enforce that as a possible mitigation, but I don’t see it in the design.

[Traktion]

@happybeing

The attack I envisage is falsifying wallet balances (or transactions)

I think this is where my understanding breaks down. If we can potentially have paper wallets with keys not being present on the network, how can transactions be made? Surely, to fake a transaction or to falsify a wallet balance you need to be able to access the wallet’s private key?

Are you suggesting that if a section was compromised, then they wouldn’t need access to any wallets, as they would just fabricate the whole thing (source wallet balance, keys, the lot)? If so, is that any different to using data objects? That is, if that part of the network is so badly disrupted, then it can fake actions?

Edit: Presumably, a general solution to prevent sections becoming compromised would be ideal here, rather than a safecoin specific solution? E.g. other stable sections confirming transactions from unstable sections and so forth.

[happybeing]

I’m not sure what I’m suggesting tbh, beyond that it looks to me like controlling a section will be far more attractive with the balance model than the coin model. If that’s not the case, then good.

But I’m not sure yet. For example, I think it would be easy to generate a wallet address that is controlled by the section you control, and then give yourself a large balance [ahem]

I’m probably wrong. @anon86652309 suggested to me my initial concerns should be addressed by the detail, but I’m not clever enough to see that myself.

[JoeSmithJr]

@happybeing

But I’m not sure yet. For example, I think it would be easy to generate a wallet address that is controlled by the section you control, and then give yourself a large balance [ahem]

What if each wallet was controlled by multiple sections?

Naive version:

• section 1: matching section for HMAC(wallet_address, “MAID”)
• section 2: matching section for HMAC(wallet_address, “SAFE”)
• section 3: matching section for HMAC(wallet_address, “RULES”)

This would make the attack you describe real hard. On the downside, we just introduced the need that sections, and not just vaults within sections, need to agree on something, so I’m just throwing it out there, not actually proposing as a solution.

[anon86652309]

@mav

Can rate limiting be used?

I think a fee makes sense but it’s nice to offer free transactions.

Absolutely agree about the free transactions. Rate limiting or something similar is pretty much what I had in mind when I said “This could potentially be handled by the proxy nodes.” in the RFC I expect a client’s proxy nodes will need to guard against other kinds of spam; basically any kind of action the client can take which is cheap for it, but expensive for the network.

@mav

Could the improved efficiency also allow reward for caching? I guess this is more about the ‘farming algorithm’ than the ‘safecoin implementation’ but being able to issue very small amounts makes the overall economic design much more interesting.

I hadn’t considered that specifically, but it’s a good point. I think we now have the flexibility to look at a few more options in terms of rewarding good behaviour. We just need to strike a balance between being fair to the farmers, but also not overcomplicating the reward algorithm.

@mav

Are parsec blocks formed from single transfer events or are they formed from groups of transfer events?

I would favour aiming for single events since that should be simpler and give the best TPS I’d guess. If we find this is unsustainable, we’d have to look again into maybe batching transactions. Parsec is still so new, I really don’t have a good handle on what wil be reasonable to throw at it!

@mav

Would the farming data be included with the network membership chain or a separate chain?

I’d probably look to use a separate chain, maybe even limited to just the Vault layer rather than held by Routing. The main reason being that I think we’ll probably be able to (and may need to) more aggressively prune this Parsec chain. We haven’t worked out the details of pruning yet, so don’t hold me to any of this - they’re just my best guesses at the moment!

@mav

Assuming blocks are batches of events, how big will parsec blocks get? Do they need to include (but not store forever) all transactions that are used to form that block (ie to verifiably update the total farmed value)? I guess the block needs to have data for a) the successful farm attempts b) the recycle events c) the failed transfer events.

I don’t know about the size of blocks yet I’m afraid, but as I mentioned above, I’m hoping we can pretty aggressively prune these chains to keep things as performant as possible. The way I see it is that the data-chain relating to network membership provides us with the ability to trust a section. On that basis, I don’t think we need to be able to prove the history of how a section came to end up with a given farmed value, we should be able to just believe it. The two points of using Parsec in the context of safecoin are:

1. to get consistency on the section’s view of the order in which changes are applied to accounts and the farmed value
2. to retain a list of the identities of transactions (e.g. the hash of them) which have been actioned to avoid double spending (replaying the request) by the client, or a malicious proxy, or a malicious node in the section

Point 2 I have mentioned in the “Unresolved questions” section, since I’m not sure yet how we’ll reconcile that with the need to prune Parsec’s chain. We have a similar requirement on Parsec regarding network events though, so I’ll reserve judgement until we have a workable solution there, and hopefully it should fit here too. If not, then I suggested a couple of possible alternatives:

We could require a client to send any request via enough proxies to be able to trust that there’s not a malicious majority of proxies. Or we could look to hold a version number in CoinAccounts so that each transaction increments this (similar to MutableData). But again these are just rough ideas and may not be required, or workable!

This isn’t an issue unique to client requests which spend safecoin by the way. We have a similar double spend/replay attack for all client requests as long as we have clients sending requests via a single proxy. This is already an issue which we’ve discussed in-houseand which we’ll need to address, regardless of safecoin.

@mav

Uncertain

• How is atomicity of transactions affected? Seems to be improved.
• How is spam control affected? Seems the same.

I’d agree with both of those.