The main benefit is “adding a strong guarantee that the receiver won’t be paid until all partial payment flows are extended.” The sender will “deliver additive shares of a base preimage, from which the payment preimages of partial payments can be derived. The receiver can only construct this value after having received all of the partial payments, satisfying the atomicity constraint.”
Even though it operates on quite a complex / different structure to safecoin payments it’s something I think is worth at least being aware of since it has a lot of similarity to the problem of atomic safecoin payments.
If the basic idea of atomic multi payment seem correct, the technical structure of both systems are so different that I don`t think that the AMP can serve as an example.
What we do not know yet are the chances that a change of SD ownership will fail. If, as I hope, they are extremely low, a request forwarded by the Datamanagers could be enough to fix the rare cases of failure in the Safe Network.
The Lightning Network is another story. The network, totally unstructured, makes the route calculation extraordinarily complex (basically a NP-Hard problem) and where the percentage of failed transactions could be very high. The AMP could alleviate these problems a bit but, even with the AMP activated, I doubt that the LN will ever be able to operate in a truly decentralized manner.
I agree they are technically very different but disagree about how useful it is as an example; I think it has a lot to offer which I’ve not yet seen anywhere in the safecoin literature.
Currently there is simply ‘hope’ that all safecoin sends and there is no partial failure (because of the necessary focus on areas other than safecoin, not because of any particular technical failure of SAFE). AMP introduces a way to ensure that payment always fully works or fully doesn’t.
All these points are from AMP and are new to safecoin:
the purchaser sends the recipient a ‘payment template’ which allows the recipient to claim payment only if all safecoin ownerships are correctly updated in the very near future.
each safecoin forms a share in the payment template, rather than each coin being individually changed to the new owner then aggregated into the final payment (possibly non-atomically). As the owner of each safecoin is updated each share becomes valid, and the payment can only be claimed when all shares become valid.
the safecoins involved in the payment are updated to an ‘intermediate’ owner that can allow one of two outcomes:
successful payment is claimed by the recipient after they fully reconstruct the key by combining the payment template + all the ‘intermediary owned’ safecoins (the safecoins are the additive shares which combine to convert the payment template into the payment key)
failed payment is reclaimed by the sender after an agreed delay (maybe n additional blocks in the datachain) to allow the recipient time to build their payment key, but also prevents the funds being permanently locked.
payment verification should be implemented using a ‘somewhat flexible scripting language’ rather than a rigid ‘signature verification scheme’. This is also related to the design of multisig payment schemes and general ownership-altering techniques wrt both safecoin and mutable data. The current proposal for safecoin payments does not allow ‘complex’ atomic schemes such as AMP-style payments because they are strictly limited to signature verification rather than script evaluation.
I have a strong hope and confidence that safecoin payments will almost always be successful in the current design, but the novelty and benefits of the atomic design in AMP is really cool and worth knowing about so we don’t restrict ourselves too much in the design and find we miss out on a potentially necessary design feature.
Isn’t this essentially like creating a wallet, transferring coins into it, then sending them the wallet? Would seem like a useful and relatively simple addition to safecoin.
I totally agree with you. Bitcoin possesses such a rich scripting language, which allows many use cases, including lightning network and AMP you mentioned. But I am afraid that safecoin will have a reduced set of features compared to bitcoin.
There isn’t any design document publicly available yet, so I can’t be sure but there are some elements that don’t give confidence.
Firstly, safecoins being implemented as MDs will inherit its limitation, namely the owner signature that is not stored in it. A consequence of this is that I don’t see how multi-sig can be implemented.
Secondly, there is no global time, nor global tick on the network, which removes all time based primitives, like transaction-level timelocks.
I’m tracking with most of this, but how does it fix divisibility? Send someone PUTS (worth less than a full coin) and let them trade them back? Still can’t get a full coin unless you save up enough puts. Or am I thinking about this the wrong way?
Well, this would hold true if people regard PUTs as interchangeable and therefore consider it valuable as would any fraction of a safecoin be. And if you can trade them back for Safecoin, then they would be.
A fraction of a safecoin (in any other divisibilty solution) is considered valuable because you know that when you have the equivalent of 1 safecoin’s worth in fractions, you will be able to get 1 safecoin for it.
So it’s the same thing. (Almost, as price would fluctuate)
If we start using PUTS as a sub-currency, now I have to track conversion rates of two separate units. What’s a SafeCoin worth? What’s a PUT worth? What’s their conversion to the other and then to USD your fiat? Two floating markets. Put price is set by the network, SAFE price is set by the market.
Not really, it creates a gameable trading situation where speculators will attempt to manipulate the free space to profit big time from this. Its just not worth the artificial ups and downs in spare space just so a few whales can profit big time. Its explained in other topics why this would happen. Only when the network is huge would this not be so easy to do.
But to answer the question, there are some differences.
The wallet object is simply a convenient collection of safecoin IDs. The owner of the safecoins in the wallet should be the same as the wallet owner, but may not always be. Transferring ownership of the wallet does not automatically and atomically transfer ownership of the safecoins in that wallet (as far as I know). This is especially a problem for atomicity. How does the network guarantee that a new wallet-object owner also correctly transitions the owner of the underlying safecoin objects? It’s the same atomicity problem as a ‘normal’ payment.
The main conceptual difference with AMP is the idea of ‘intermediary owner’, which wallet transfer does not have. AMP has an intermediate step to ownership, where the receiver cannot yet claim the coins, nor can the sender. There is some extra process to move out of the neutral owner (either the receiver builds the key from the template, or the sender waits for the unclaimed payment timeout). That extra process is what provides the atomicity.
Fair enough, that is very true. I am seeing this from the perspective of a massively successful network though, being very large. That makes conversion rates an academic problem as well.
At that stage.
But then there is all the time up until global adoption and during that time it would be problematic.
If Safecoin knew what wallet it was contained in this could be solved.
Safecoin knows:
Current owner, previous owner, wallet it’s in. → Can only be spent if you own wallet and coin.
Sending:
A wants to send 10 SAFE to B.
A creates a new wallet, sends his own 10 SAFE to it.
A transfers ownership of those 10 coins to B (but not the wallet).
Once all 10 coins are owned by B, A transfers ownership of wallet to B.
Then you only have a single transaction that must succeed, therefore, atomic.
What if the wallet ID is the owner of each coin, and the account id that is the owner of the wallet is then regarded as the coin owner.
That would make ownership change of n coins a single step.
Not sure there isn’t some fundamental issue with it though… breaking something with regards to the individual coin handling from a wallet by an account…
What if only 8 of them go to B and 2 fail and remain with A? A tries sending the 2 again and again but those 2 just don’t get there. A finds it all too hard (they’re at a checkout with a long line and a crying baby in their arms and …) so gives up trying to send to B. How does A reclaim the 8 coins? B can’t claim them since they don’t own the wallet. Nor can A since they aren’t the safecoin owner.
Drawback here is that each coin sent is potentially lost, without being fully transacted.
If ownership inheritance is used,there is never anything in limbo.
You then transfer the n coins back and forth between your main and new wallet, and only send with the single ownership transfer of the wallet.
EDIT: With an ownership tree for all network addressable objects, where actual owner is the root,any size of the tree can change ownership with one single step.
Yes and it could even cause the network to be abandoned because of all the issue with free space being massive then disappearing and the network PUT costs going from near zero one day to a few PUTs only per coin.
It has the potential to keep the network academic because of the problems. And the discussion has many aspects to it and is also academic at this time.
Once you do that B owns those coins. Everything else if fluff
Its been told us that the new owner is sent a message once a coin is transferred to that ID. Otherwise wallets could never know its happened.
I have my doubts (but no proof) that it would take more than 1-2 attempts with so many vaults managing them. With multiple failures, there are major issues with the network. (That’s not the point I know, just saying).
This would be great. I’m having trouble picturing how this would work technically, but I’m very intrigued.
It hasn’t been designed yet. All subject to change. The alert could come when wallet changes. If the coins can’t be spent unless wallet owner and coin owner match, then it’s still viable.
Hmm. Mm. So, the problem I’m thinking about is determining ownership.
Any size of data tree can be transferred, with same speed as a single object.
But determining the root of a tree, well, that will take longer the bigger it grows. It is somewhat similar in principle to the wallet protocol Seneca presented a while back actually.
EDIT: (With the exception that there it was never ending, like a block chain, but ownership trees can be split and combined to flatten them out)
But would it be a problem? In the extreme case, when you get to the root and finally find out who the true owner is of the leaf, he might already have transferred ownership to someone else.
Now that is eventual consistency problem. And we actually always have it, since things can always change in the time it takes for the information to reach you. But the practical risk for actual problems as a consequence of it, naturally grows with the time.
EDIT: I guess the likely hood for such a deep inheritance tree that it would become difficult to properly determine user, would diminish proportionally to that depth.
It would be a quite absurd construct for it to be noticeable. But then again, with things like this it is always foolish to think one knows what is likely Possible use cases and turnouts of events are rather vast and our capacity to grasp, not so large
So, that would be some entity owning a lot, and doing a lot of transfer of it, and so wanting to keep inheritance deep as to not spend energy on flattening only to later again have to deepen before a large transfer… I can see how that is actually plausible.
They themselves would not see problems, they know what they transferred and not
But if there is some public audit of it of sorts, then the observers would be closest to run into problems by it, I think.
Possible use cases and turnouts of events are rather vast and our capacity to grasp, not so large