Fraser's Safecoin Alternative Design (Postponed State)

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.

5 Likes

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.

8 Likes

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!

13 Likes

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

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

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

1 Like

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?

5 Likes

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.

4 Likes

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

5 Likes

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.

4 Likes

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.

4 Likes

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] :laughing:

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.

4 Likes

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.

4 Likes

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 :slight_smile: 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.

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.

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!

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! :slight_smile:

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.

I’d agree with both of those.

7 Likes

You’ve seen the delights of Troon… surely one Troon is more than enough?! :smiley:

4 Likes

Yeah - I’m gradually coming round to your way of thinking here (and you’re right @neo, I was mistakenly talking about responses going all the way back to the client rather than just a refund).

I had my suspicions when I wrote that part of the RFC that there might be kickback :smiley:

Possibly there’s a middle ground where a client is allowed a few “mistakes” before we start not refunding. Or we refund a decreasing percentage of the transaction as failed attempts increase. More complexity is bad, I know, but I also don’t want to encourage a malicious client to squander network resources by transferring to a myriad of non-existent accounts.

5 Likes

I think @draw has already nailed the answers here and here (although just ignore the bits where talks about lack of understanding! :smiley:).

Just to give my view; I’d say the new approach is a wee bit weaker than the old in terms of a malicious user getting control of a section. This is mainly because of the ease with which they could dump coins into their account though. It’d also be easier for them to create more coins than should exist. I don’t think the old approach was immune to these problems, it’d just be more work for a malicious section to achieve its goals. (With the old approach, they couldn’t really create more coins than should exist, but I think they could spend a coin held by their section from an account held by their section mutiple times, which would be almost equivalent, although probably more detectable.)

It would indeed. But with the old proposal, you’d be able to do similarly. You’d just create a wallet in your section and pretend it holds every coin that can exist in your section (you don’t need to actually create the coins). Then when you want to spend the coins, the destination section where the recipient’s wallet lives assigns those coins to the recipient, but your malicious section is still free to pretend you own them. You can pretend to transfer ownership of those same coins to as many different destination wallets as you choose.

To me, safecoin (in whatever form) incentivises malicious actors to try and get control of a section, but even without safecoin the temptation is pretty high. I think we need to mitigate against malicious sections under all circumstances, so I’d see the details of how we approach that as outwith the scope of the safecoin RFC. As in, if we decide for example neighbouring sections should monitor each other, then I think they should monitor more than just their handling of safecoin.

Having said all that, I may be missing something (I wasn’t thinking much about mitigating against a mailcious section when forming the RFC) and the new approach possibly does offer even greater incentives. If so, we’d definitely want to document those in the RFC and they may be severe enough to be grounds for preferring the old approach.

6 Likes

This is very similar to ideas we had for ImmutableData a while back. We had RFC-0013 and RFC-0023 describing this.

3 Likes

“Nano” coin has free transactions but requires a proof-of-work for each transaction - but these can be done in advance and stored, so they don’t cause any delay in the transaction speed. I have no idea on the details, but it’s an interesting idea.

3 Likes

Yea, I am getting the impression that the reduced protection compared with the inherent protection that MDs gave needs to be offset with involving at least 2 sections when dealing with the coin accounts and “farmed” amount.

With the MDs only one ID (or set of IDs) could own the MD and the compromised section could only change ownership of the MDs it had control over. Didn’t matter what any wallet said it had, the coin could only be spent if you had the private key for it. So the taken over section would simply change the owner of the MD.

Now with the coin accounts as you and others mentioned can simply keep sending (made up) coins from that section to the attacker’s account.

There needs to be a secondary check to ensure a taken over section cannot just create a coin account and it have billions of coins in it. Obviously the attacker would have the keys to this account. Maybe the coin account is actually kept by two sections and version number can be used to verify sync. Both sections have to agree on any spend. If a taken over section just creates a coin account with coins in it then the other section has no record and so no spending can be validated and executed. You could have the secondary record of the account use the inverse of the ID so that it is located elsewhere in the network in another section (except when you only have one section :stuck_out_tongue_closed_eyes: )

4 Likes

Instead of using multiple sections for governing a single network coin account, would a fuzzy form of the classic approach help minimize damage? This would involve using multiple network coin accounts per section that are restricted so that each of them could never contain more than a single safecoin (I think this is what your original balance idea for divisibility did right?).

In a broader context, we’ve discussed how all bets are off within a section once it gets compromised, for safecoin or anything else. I recall mav or tfa doing some work to show what percentage of the global network needed to consist of adversary nodes in order for a single section to become compromised. Using dual or multi-section checks on transactions would appear to fix this issue, drastically reducing the probability that a single section could ever become compromised and help identify bad nodes for removal. A way to do this may be analogous to RAID 1 mirroring at the network level. MAID 1 anyone? :sweat_smile:

A simple and naive way to approach this would be to partition the network globally. Client requests and commands get simultaneously issued to each and parsec runs independently in each half, then each section checks the work of it’s partner in the other partition to make sure they same end result was found. Inconsistencies would get flagged and corrective measures could then be implemented. In a perfect world you might have two exact copies of the network running side by side. Sections and nodes would likely differ due to the complexities of dynamic section membership, so it’s highly unlikely the network structure would be identical in both halves but the data chunks must be. I’m sure there are more elegant ways to go about this, but I think you get the basic idea. As an analogy, consider the human brain with its two hemispheres, or bilateral symmetry in general where the right hand can tend to the left, or vice versa.

3 Likes

Maybe you store every chunk on 2 sections: the ‘official’ one and a backup: determined using the ‘inverse’ (XOR address) or something similar. This way everyone who has the XOR address of the chunk knows where to find the backup. And the ‘backup’ of a section as a whole is distritubed over the complete network and not all concentrated around the same address space/section.
The backup can also be used to check against, like in the case of SafeCoins.
It could be that this kind of approach introduces bigger problems then it tries to solve, but I certainly see advantages.
Though this ‘inverse’ solution probably doesn’t work for Safecoin Id’s. An attacker can make a Safecoin id where the inverse falls in the same section or in another section he also controls.