Atomic safecoin

I still remain skeptical about the safeCOIN model and how it will work. I was wondering if somebody could address my concerns and explain how it is going to work…

My understanding is that when I spend a coin, My wallet signs an order “Give coin abcd to Bob” The consensus group around the coin votes on weather I am the owner of the coin and if my order is properly signed, and if 28 of the 32 nodes agree, It becomes Bob’s coin.

Is that correct?

If I spend 1000 coins, that would mean 28000 of 32000 nodes would have to approve my purchase, because each coin has a different consensus group that know who the coin belongs to.

If 999 of the groups agree and one dissents, do to a double spend, or perhaps just network churn, what happens? Are the other 999 canceled as well? How is that communicated and verified amongst the nodes that may be churning? What if Bob has already spent some of the 999?

Curious to know the thinking and strategy on these issues… Or perhaps I am missing something.

Kind of (we are working on the numbers for consensus, so possibly not 32). If Quorum of the group agrree this is a valid transaction (your signature makes it your coin if its a valid successor transaction) then the coin is transferred, otherwise the transaction fails.

Each coin will transfer independently, so unless you were acting maliciously it would all be OK, if you tried to double spend then the first transaction to settle would invalidate the other transaction.

3 Likes

Hi Irvine, so what are other options if not consensus of 32 ?

authority of 1 :grimacing:

1 Like

Thiknk more of group sizes, so we have sharding already in place. Each group will reach consensus. A group can be from 9 -> approx 50, some of the group will be Elders (probably 8) and the rest adults and 1 infant (sometimes 2). Group consensus is >50% and ordering consensus is >2/3 of nodes in agreement. So take 8 as the Elder size for now if that helps?

6 Likes

So it means that group can change dynamically size based on number of Elders, adults and infants ?

Sections grow until they are able to split. There is a lot of data about it in this thread: https://forum.safedev.org/t/data-chains-deeper-dive/1209?u=drehb

3 Likes

How the malicious actor would be handled? If the transaction is non-atomic and the merchant receives 5 to 95 percent of the coins, does it leave the burden on the merchant and the purchaser to sort out the mess? (or not) With most cryptocurrencies, you either get paid, or you don’t, there is no “partially paid”…

@jreighley how do you know “partially paid” is possible? You have 1000 coins and you send them or you do not… the same is like having 1 bitcoin and sending 0.99… for something that costs 1 bitcoin…

The reason for a consensus mechanism is because it is possible that the answer is no. Bad actors exist. Consensus groups churn, Network connections go up and down. We cannot assume every answer is going to be “yes” .

If I send 950 valid coins, and 50 that I attempt to double spend at the same time, It is quite possible that I get 950 successes and 50 failures for example. That is indeed what should happen.

If I am a vendor, I now have 950 coins, each independently verified and granted to me by the consensus group, but 50 failed for whatever reason. Is it the burden of the vendor and the customer to sort this out? What if I am not a good actor, and I refuse? It seems to me that “All or nothing” transactions are needed for a currency to be trusted and adopted.

If you’re a bad actor it doesn’t matter whether you received 950 coins or the agreed 1,000, so I don’t think that’s relevant.

It seems pretty straightforward to me. If you agree to pay me a given amount and too little arrives, it is up to you to make up difference.

For situations where that isn’t an acceptable risk, such as very large amounts, then an escrow service might offer an alternative, but if SAFE works reliably I doubt that will be necessary and we’ve no reason at this point to believe it won’t. If it doesn’t I think we have much bigger issues to sort out!

People will learn to trust the system based on preformance, and there is as yet no reason to think this will be an issue at all (ie sending 1,000 coins and some not being transferred).

If that happens because you are trying to game the system, then sure, there’s an issue, but in this situation the vendor is not at risk. Only the person who tried to defraud the system so I think that’s a good disincentive to try this.

Eventually things like this might be handled atomically through smart contracts on SAFEnetwork, but I don’t see the situation you’ve described as likely to be a problem at all.

3 Likes

In theory, you can get the exact same problem in bitcoin by not paying the correct amount. It just would be very clear that that was what happened.

I don’t think the “If you are a bad actor it doesn’t matter” defense holds up. The network doesn’t know bad actors from good. Software behaves as it was programmed to behave, and it doesn’t know what is good or bad. A double spend could be the outcome of a race condition with no evil intent.

It seems to me the ideal solution would be to have atomic transactions, but I figured that would be quite difficult on SAFE. Sounds like my analysis is correct.

The other question would be how the vendor is going to be informed of coins that arrive. I assume that if somebody sends me 1000 coins, I am going to get 1000 confirmations each telling me who the prior owner is? Does it provide a master transaction index so I can count them up? If I have 100 multiple coin transactions going on at the same time, it could be quite confusing without some top level identifier to sort upon. Prior owner wouldn’t necessarily be enough, as I may have multiple transactions with the same parties.

I would add that a client could automatically retry to send coins which failed or send alternative coins if available.

Also, could create an account with a full payment in it, then pass account to other person. This would be atomic and could have 2 benefits:

  1. Atomic transaction.
  2. Fully anonymous transaction could be achieved if done twice, as first owner is scrubbed.
4 Likes
1 Like

That is exactly what Maidsafe does. They program things to behave. Think, node aging. This is a bit different but nothing that isn’t solvable, if an issue at all.

I like that answer. I think create another account sounds like a “hack around” but you could fairly easily build that into a feature, particularly if it was possible to change the owner on an account, just like it may be possible to change the owner on a coin. You could still have a bit of the same non-atomic problem moving coins between accounts, but at least it is a one party problem… Much easier to trust yourself.

I suspect that if it became a popular use case, atomic transaction groups could be implemented in a seamless way too. I think it is good that an account can be used as an atomic container for coins though, as it proves it can be done.

2 Likes

I’m yet to even get onto the SAFE network and I’m learning so much from you @Traktion, ‘Atomic transaction’ is a term I’d never heard of before (admittedly I’m not a programmer, googled and it’s over my head), so seeing this network being built around this forum is encouraging for a newbie. I have used Steemit (I know SAFE is HD oriented), so I understand the monetary system within that platform in respect to crypto currency, but now eagerly awaiting my invitation to see how the SAFE (testnet) network runs.

3 Likes