Currently to my understanding what you describe is a wallet (ie a wallet is a list of safecoin who share the same owner). But that isn’t formally specified anywhere yet.
From RFC-0012 Safecoin Implementation: “The safecoin close group then send a receipt message to the wallet address to inform the user of a new minted safecoin allocated to them.”
So the wallet does track safecoin, but there’s no specifics of how. There’s some info in Account Management but it’s not clear to me: “when being notified by the sender’s account group and the safecoin management group, the correspondent safecoin’s ID will be inserted into the record.”
A new wallet identity? That’s a good question and one which doesn’t currently have an answer. Presumably the safecoin in the wallet are automatically moved to the new owner as well. Or maybe wallet ownership is ‘locked’ and it’s invalid to change wallets to a new owner, ie only safecoins can be moved?
A new safecoin identity? Well, it’s just automatically built into the ownership model of MDs.
The doubt lies in the aggregation of safecoin into a wallet. If they get out of sync, what happens? Safecoin itself is pretty solid from an ownership perspective, as is the ownership of a wallet object, but the syncronization between the two… that’s unclear.
No, this isn’t true. The benefit of AMP is that it’s still only two parties in the transaction - the recipient can claim the coins by recreating the key from the template+shares, the sender can claim by waiting for the HTLC to timeout. But there’s only two parties, no escrow. I describe this ‘in between’ state like it’s a third party, but it’s not. It’s a third state but only two parties are involved.
Wallets could store their safecoin IDs within the data part of the MD (which is a key value store, see the mutable data RFC link by digipl above).
Safecoins could also store their wallet ID within the data part of the MD.
This creates a link both ways between wallet-to-safecoin and safecoin-to-wallet.
Is it necessary? Maybe not. It would be necessary for the idea wes has, but there may be other ideas that don’t require it.
No, you’d just need to steal the wallet then claim all the coins in it are stuck (assuming there is an mechanism for recovering stuck coins). If no mechanism then yes the attacker needs to steal both wallet and safecoin which is much harder and more secure.
Good thinking on the privacy side of things. Perhaps the wallet id itself is not stored but as hash(salt+walletId). This way someone looking at the safecoin can’t know which wallet it belongs to, but the wallet owner can easily supply the salt to prove the coin and wallet are connected if a reset is required.
To elaborate on the privacy, presumably wallets contain an encrypted list of safecoin ids for privacy purposes. This means the network cannot simply look ‘inside’ the wallet and do a comparison with the safecoins in it and reset any that are stuck. But what can be done is the wallet owner can request the network to change the encrypted safecoin list to any new value of their choosing (ie their encrypted reset values) and so long as it’s signed by the owner the network simply does it. If they choose to set their list to an invalid value and loose track of their coins, well, that’s up to them.
I think the atomicity via wallets idea is getting quite complex once privacy is added and needs a flow chart to identify weaknesses
Labelling the ‘atomic payment mechanism’ as ‘a new wallet for making an atomic payment’ is misleading. What is really being performed is the creation of a ‘payment preparation area’ where mistakes can be reversed, and then once the payment is prepared it can be atomically sent. Calling that preparation area a wallet is (to me) using a name at the wrong level of abstraction (even though it’s a similar process to creating a new wallet).
They aren’t, because none of them requires a third signature. They all involve a third state, which puts the payment into some sort of limbo either-can-claim position, but that third state is not an escrow. This is important because there is only two parties in the negotiation. Escrow is a three party negotiation (even if the third party is fully automated). I guess if the two parties initially negotiate and agree to how the escrow will work prior to transacting then the escrow is ok, but escrow is fundamentally a different concept to the ideas discussed here.