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.
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.
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.
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.
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!
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 @Fraser 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
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.
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.
What if each wallet was controlled by multiple sections?
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.
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.
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!
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:
to get consistency on the section’s view of the order in which changes are applied to accounts and the farmed value
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.
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
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.
I think @draw has already nailed the answers here and here (although just ignore the bits where talks about lack of understanding! ).
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.
“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.