If possible it really would be good with something that doesn’t require the recipient to be active. Even though it is an app, since it either requires user to be online (run the app), a server to host it, or a decentralised app (more latency and complexity).
1 Like
This go against the Apps rules. The apps are not allowed to do ownership transfers and allowing it, could become a huge security hole.
No, you are misunderstanding.
Recipient becoming owner of a network object, means that the owner field has an ID of which the recipient controls the private key. The easiest way is that this is an ID the recipient has since before.
There is no security hole in this, and it is not against any app rules.
So, again, the best thing for automation, is that a recipient does not need to be active.
1 Like
Excellent summary of the entire topic I think. Some change will be required, it’s good to think a bit about what that may look like.
You say atomic payments ‘could be’ a function of the app which is true - they could - but atomic payments shouldn’t be a function of the app.
Atomic payments (and database transactions in general) are essential to ‘just work’ at the network level. Merchants having to ask customers ‘what wallet are you using’ to debug partial payments is crazy.
If developers don’t have access to database-style transactions it will greatly affect perception and adoption of technical users. Transactions are a pretty basic and fundamental feature of any data store.
Maybe a library to support atomic transactions might be enough, but I reckon network level is the way to go. Although I’m open to being convinced otherwise.
I can’t endorse sharing private keys (even temporary ones). I think this mechanism would fail too frequently to be viable.
I put this in the same basket as showing an image of a padlock to indicate security of a website; sharing private keys is something that should never be done, even if it’s under ‘safe’ or ‘correct’ or ‘legitimate’ circumstances.
But I know you are simply providing an example, not a proposed solution, and the example sounds good other than the matter-of-principle wrt sharing private keys.
The current RFC proposal is each coin transferred will have a notification to the recipient. So a 5 coin payment means 5 notifications. There’s currently no ‘payment’ structure to wrap all those individual notifications up together. Presumably the recipient receives each payment to a unique ID so they can distinguish between individual simultaneous payments.
I feel BIP70 Payment Protocol is worth a mention here since it includes a field for return address. It never really gained much adoption and I personally don’t like it (and I say that having implemented it for merchants). I understand the benefits but the x509 shit and the protobuf shit (and so many other things) made it much more difficult than it needed to be imo.
Payment protocols should be simple and there are good things we can learn to do (and not to do) from BIP70.
5 Likes
I don’t really understand this sentiment. We share temporary “private” keys all the time. Most of the major communication protocols we use today share temporary keys (e.g. SSL/TLS, SSH). It’s a ubiquitous way to help speed up encrypted transactions.
1 Like
But could be an easy modification unless some proposal that need deep changes in the MD structure. In fact the basic MD ownership transfer only indicates a response to a transfer ownership RPC requests so it would not be necessary to modify the design of the MDs.
Response format:
pub enum Response {
…
ChangeMDataOwner(ResponseResult<()>, MsgId),
…
}
We only need a simple function of packaging transaction notifications.
1 Like
Those are public keys. Aka, anyone can write using them. Private keys let you write as an authority/identity and should therefore never be shared.
They exchange a temporary session key (also called shared keys, or symmetrical keys) with public keys, and then use that session key for communication. Communication with public key infrastructure is extremely slow as opposed to having a single shared key.
1 Like
Correct, they’re sharing symmetric keys. Different process than public/private encryption. It sounds like semantics, but the difference is quite large.
1 Like
I don’t understand your point. Yes, symmetric keys are different then a public/private keypair, but the thoughts behind it are the same. You want to protect what is yours from an intruder. We already pass keys around with each other, so passing a key is not a new concept. Whether you are passing the private key of a public/private keypair, or a shared key is irrelevant. In either case, you are giving another person access to your data.
Unless the concern is that coding a mechanism to share private keys of a PKI infrastructure can lead to exploitation of a user’s personal wallet not used for transactions, there is no fundamental difference.
1 Like
I agree that we use shared keys and the technical precedent of sharing keys in those contexts is not the issue.
Using the quote below it will hopefully be clearer why I don’t like the shared key idea. It has to do with accountability.
If the coins in the shared wallet are transferred somewhere other than a place the seller controls, who is responsible for the loss? The seller says ‘you sent them back to yourself’ and the buyer says ‘you sent them to the wrong place’. There’s no way to verify if the bad transaction was due to the buyer or the seller or maybe even a third party that has somehow obtained the key (malware etc).
This is the problem with shared keys in this context. There needs to be accountability and that only comes from separate keys.
So I agree with your point that we use shared keys, but I still don’t think shared keys are appropriate for payment mechanisms.
5 Likes
The recipient does not need to be active at all. The recipient does the transfer when they accept the payment minutes or days or year later. Think mail order with the check in the mail. The buyer can retrieve the cash in the cheque until the seller banks the cheque. This is similar where the buyer writes the cheque (puts coins in new wallet ID) and the seller banks the cheque (moves the coins from that wallet ID
Just like cheque is lost in the mail. The seller says no mate I didn’t get the coins.
With any payment the seller could claim he didn’t get the coins and under SAFE there is no way to prove the seller didn’t move the coins and say they didn’t get them. The buyer cannot prove it.
Remember one of the main reasons for atomic transfer of multiple coins is to ensure all coins are transferred or else none are. Even with this the seller can still claim not to have received the coins by simply moving them to another ID
No mate, that is exactly what being active means. “The recipient does the transfer…”
I am talking about the balance increasing even if the recipient is in a coma.
Your usecase is not realistically applicable for all types of transactions. It’s how things were done before we could automate them.
EDIT: The way safecoin has been RFCed is that the receiver HAS to be active (your definition of active). When a SAFEcoin changes owner the new owner receives a message telling them they have received a SAFEcoin. Unless the recipient is “active” they do not know about the received coin and since they don’t know of it they cannot use it.
The message is used by the recipient to know they have received the coin and the address of the coin. It would be logical that a wallet APP will be checking the message queue for message informing the user that they have received the coin.
So without running an APP the coin sent is useless since its not known about.
This idea of mine just above is similar except that instead of populating the coin address list the wallet APP moves the coins. Similar action in that the recipient has to be active to know they have the coins.
No mate 
you are now splitting hairs, and its terminology, let me explain how it is both not needing to be active and how it is being active.
A seller will want to move the coins sometime won’t they. Like the cheque in the mail, the seller can sit on the cheque and risk the cheque being worthless sometime. A seller is always doing work.
Technically and practically speaking the recipient has received the coins by doing nothing. The only issue is that they risk losing the coins depending on how honest the sender is. The recipient technically has received the coins without doing the moving.
This is only for atomic style of sending multiple coins. Normally it is not necessary. Say I want to give Mary 1000 coins, then I just send 1000 coins and the wallet keeps retrying (if needed) till all 1000 are sent.
For the buyer seller scenario then atomic transfer of multiple coins might be used if the buyer desires it. It normally is not needed.
I doubt there will be any one size fits all method of sending coins apart from the sending of one coin after the other and retry till all done.
1 Like
As @mav, the possibility that both, the buyer and the seller, have access to the same safecoins seems extremely dangerous to me and a source of problems. Much more in a system of anonymous transactions where no record remains.
Maybe we could find a solution using multisign. The modified steps would be the following:
-
The buyer sends the required number of safecoins to the new ID with a multisign buyer-seller (2 of 2) and checks all sent ok
-
The buyer changes ownership of the “wallet” data structure to the seller and sign the transfer of all coins.
-
The buyer sends the private key of that ID to the seller. In this moment only the seller can access this safecoins.
1 Like
I think multisig is easier than what you say without sending any private keys. My example method was for single sig as MDs are now.
- give all coins to be sent a second sig and that is of a second ID that is yours
- give all coins to be sent a third sig and that is of the seller.
- at this stage the seller cannot do anything with them but could see them if they wished.
- remove both your sigs from the coins
- if you could add your second ID and the seller sig then you should have no failures with removing your 2 sigs. If you did then I doubt any atomic transfer would be working either.
- the seller now own the coins outright.
No need to send private keys and the reason for you having 2 IDs initially is to prevent the seller operating on the coins before you are ready.
Your first step though still have the issue of potential failure if for some reason there is an error. The seller will have some coins and refuses to accept payment till all coins are sent. If for some reason you had to back out then you cannot get back the coins already sent.
My idea was to do the ownership in steps and assuming the 1st 2 steps worked then the last step of removing your 2 sigs should work “no matter what” and if and only if it didn’t then the only down side is you still have control of those coins until the removal of at least one sig works.
2 Likes
That’s, at least, three ownership changes, maybe too much for a single payment…
In fact, using multisign we can reduce the steps of your proposal and never, buyer and seller, share the same safecoin.
- Seller asks for payment and send a public key
- The buyer creates an ID
- The buyer uses that ID and creates a “wallet” data structure
- The buyer sends the required number of safecoins to that ID using multisig 2 of 2 (NewID-Seller public key) and checks all sent ok (in this moment neither, buyer or seller alone, can access this safecoin)
- The buyer sends the private key of that ID to the seller. The seller check that all is OK (can transfer this safecoin to his own wallet but is not not essential since nobody, except him, can access these safecoin)
- The sale is now complete
1 Like
Removed. …