Atomic Multi-path Payments (bitcoin)


#21

There’s a way this process can work nicely with a bit of tweaking. Add a mechanism for asking the network to reset stuck coins in a wallet back to the wallet owner.

Modifying your procedure with my italics

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.
Only 8 of 10 coins are transferred to the new owner, and 2 are still owned by A.
The sender signals to the network there are stuck coins in the wallet.
The network changes the 8 stuck coins back to the wallet owner.

This acts like the reclaim process of AMP and would only be done if there was some sort of payment failure / stuck coins. It’s easy for the network to determine which are stuck coins since it’s a simple mismatch of wallet vs coin owner. It’s fully verified with signatures from the wallet owner so can’t be abused or faked. It should only be needed as a safeguard and most payments would work as intended first time almost all the time. But the ‘what if it doesn’t work’ question needs to have an answer; this might be one possible answer to atomicity. Nice idea wes!


#22

But, does a coin have two (current) ownership fields? An “account” and a “wallet”? That is the suggestion then?
Without ownership inheritance, I would have thought that the wallet is an MD owned by an account, and the coin has no awareness of the wallet, it only knows of its owner (in singular) and previous owner (like any data does?), the wallet is just a registry where you as owner can keep track of your coins.

Would it be preferable to special treat safecoin to have two current ownership fields, over introducing ownership inheritance? Because with the latter, the former special treatment is not needed it seems to me. But it is on the other hand a change with smaller impact it seems.


#23

Just the one ID. That is the wallet ID

BTW what is the account ID? I thought an account had any number of IDs contained in the account data and the account itself is just the record (data) decoded when you log in. Within the account data you will have the IDs and their keys and usually at least one will be a wallet ID, and that ID could also be your ID you use elsewhere (forums, shopping, etc)

Actually owned by an ID. And thus referred as the wallet ID. The MD is the wallet datastructure. The ID could also be the ID you log into shops and thus is your “shopping” ID as well, both being the same ID with the same private/public keys

When multi-sig is introduced then safecoins along with MDs in general can have multiple owners.


#24

I like this. We would basically be adding these requirements:

  • safecoin must be assigned to a wallet.
  • If the safecoin owner does not match the wallet owner, it is in a transitional state.
  • if the safecoin is in a transitional state, the network can be asked to reset the transaction, which changes the safecoin owner back to the wallet owner.
  • if the safecoin is in a transitional state, the safecoin cannot be spent (transferred) by any user.

#25

I must be a bit groggy by heat because I do not understand some of the proposals.

A wallet is not a list of safecoin who share the same owner?

If we create and transfer a new identity, how do we ensure that the previous owner can not access those safecoin?
Changing the owner of the wallet does not prevent the previous owner from knowing the Xorname of each safecoin and retrieving the safecoin with a request to change ownership.

If we copy the MPA, we need an intermediate step and someone with the power to sign the change of ownership. Who will have that power? How do we ensure that it is done correctly?

Safecoin assigned to a wallet? How? a safecoin is an MD and, unless a different type is created, it must comply with the basic properties of all MD.


#26

The way I am thinking about it, is having a wallet MD and a requirement for SAFECoin to be assigned to a wallet MD. I am assuming this could be through some meta data stored within the Safecoin MD, if no generic attribute can be purposed for this.

When a user needs an atomic transaction, they:

  1. create a new wallet MD
  2. assign SAFECoin to it
  3. change ownership of safecoin to receiving user
  4. change ownership of wallet MD to receiving user

If 3 is not completed, the network could be asked to revert the step. Arguably, that isn’t necessary, but network issues could cause some safecoin to be locked in limbo.

It would mean that owning the safecoin MD alone would not mean you could spend it; you would also need the wallet.

Hmm… thinking on the wallet/safecoin dependency, this could add coin security. To steal a coin, you would also need to steal the wallet too, as otherwise you would just have a limbo coin. Edit: moreover, just stealing the wallet would make the assigned coins limbo coins. Edit2: but ofc, you would need a way to sign wallet assignment which couldn’t be done by the thief; maybe that isn’t feasible and security would remain as before.


#27

Not read every line so forgive any stupidity…

I think the Safecoin knows wallet idea is fine, but that the wallet field should also be allowed to be blank. Otherwise Safecoin might be starting to become trackable.

Perhaps the field should normally be blank, and only given a reference to a wallet for this specific purpose, and once transferred, reset to blank.

Such transacting would therefore incur a cost (PUTS) which might discourage those resets to blank (if optional) and lead to a lot of Safecoin holding the address of a wallet.

In which case I think we should think about that, and whether there are unintended effects such as leaking information. If so, perhaps that needs to be considered.


#28

The wallet ID is the owner ID stored in the coin. There is no real account ID as an account data contains any number of IDs used for various purposes. The owner of a safe coin is just a ID that *you* know the private key for


#29

Giving it more thought, I think the limbo (mismatching wallet/coin ownership) coins would need to be un-spendable. This would suggest using a special field (with specific rules) instead of just meta data which can (just) be changed by the owner. It would all security though, as stolen coins would be in limbo too and also unspendable.

Anyone with a deeper understanding of MDs know whether this can be configured? Can some fields only be changed from one state to another, when a specific, different user allows it (e.g. if the previous owner signs it)?


#30

This wallet is older than 12 months, so you’ll need safe-browser-v0.7.0 to access it.

Maybe you want to check out our wallet at safe://plimst.moinho to see how PUTs work with token creation. Creating 10 coins costs 24 PUTs, 20 coins costs 44 PUTs and 100 coins costs 204 PUTs. It seems like the more tokens you create the less you pay per PUT. About divisibility, the token needs to know how much it’s worth in PUTs and because the SAFE Network will be constantly changing the PUTs value per token will constantly change I think. Unless somebody comes up with a way to make 1 coin cost 1 PUTs. Don’t try to create 1000 coins, that will eat up all your PUTs.

:stuck_out_tongue:


#31

We have the RFC of Mutable data.

and we must remember this:

Transfer of ownership

Ownership transfers are a special case. The apps are not allowed to do this operation. They will need to ask the Authenticator to do this. Maid-Managers shall enforce that change_mdata_owner only comes from the owner. Data-Managers shall enforce that current owner of the data matches the incoming Maid-Manager group.


#32

These proposals seem like a bastardized version of an escrow system. If you want to make an escrow-like system, just make an escrow system.

1.The network has its own “user” to control transactions, lets call it “User X”
2. Coins have three attributes (current owner, previous owner, transfer user)
3. User A starts a transaction with User B, and agrees to pay the user
4. User A sends coins to User X. User X is now the current owner, User A is the previous owner, and User B is the transfer user
5. User X verifies the coins have been transferred successfully (User A isn’t doing something nefarious)
6. User X can now send the coins to either A or B, whoever initiates the transfer first.
7. If User A cancels their transaction, User X sends them back to User A and the “transfer user” attribute is wiped out.
8. If User B accepts the transfer before User A cancels the transaction, User X sends the coins to User B, wiping out the “transfer user” attribute, and replacing the “current owner” attribute with User B, without touching the previous owner attribute (who is now User A).

This also could be used to increase security for those that are particularly paranoid. Initiating a transfer to one of your other wallets, and the cancelling them would wipe out the previous owner attribute, making it more anonymized.


#33

A lot of mixups and complication here it seems to me.

Anyhow, if we are talking about the possibility for any network addressable object to be an owner of another, we are per definition forming an ownership hierarchy.

I really don’t see why that 8-step suggestion, (or any n++ step variation) would be preferable over just signing over ownership of a tree of n-depth, effectively transactioning arbitrary amount/size of objects/data/ information in one single step.

Much broader application than adding fields this and that to MD’s if this and that.

My 2 cents.


#34

I didn’t mean to say my suggestion would be preferable. I don’t think it is. I was just addressing the proposals that are trying to create an escrow-type system, and how it could actually be done correctly. You can still do the escrow proposal with a n-depth tree. What you would be transferring to the escrow would be immaterial, as long as it can verify the contents are correct.

  1. User A creates a wallet and puts coins into it
  2. User A sends wallet ownership to User X
  3. User X verifies receipt of Y number of coins in said wallet and waits for transfer request
  4. User A or B requests the wallet, and User X assigns ownership of the wallet

#35

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 :slight_smile:

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.


#36

Some things we know

  • Owner field in the safecoin is an ID
  • The ID is the public key of a public-private key pair
  • The account has zero to many IDs stored in data area. Zero IDs is of not much use :slight_smile: and one expects there to be a few.
  • One or more of the IDs in an account will be for receiving safecoins and the ID will be what is stored in the safecoin as the owner of the coin.
  • You need the private key of an ID in order to spend the coin.
  • A wallet is really a data structure of some sort that holds the addresses of the safecoins owned by an ID. A logical situation is that the wallet data structure is one or more MDs holding the required information and addresses of coins. The primary MD of a wallet would logically have its address as the ID of the coins it holds the coin-addresses of. Maybe it has to be a reserved tag type so that predatory grabbing of those MDs used as primary wallet MDs cannot be done
  • Thus a wallet is no more than just a convenient way to know what coins have a particular owner ID.

Knowing these things, atomic transfer of multiple coins is not really possible without some core support. Even @Traktion’s idea, while good and simple, cannot be done since transferring the wallet data MDs to a new owner is not actually transferring the coins to anyone since the original person still has the private keys of the ID which is the owner ID stored in the safecoins and the original person could still spend them. Also the receiver doesn’t have the private key of the ID either.

Now when we think of real life buying goods with actual cash, the sale is not complete until the buyer lets go of the cash and the seller can put the cash away. With transference of many safecoins then the transaction is not considered complete until all the coins are transferred. So it is really up to the person sending the coins to ensure all are sent. This could be a function of the “wallet” App the sender uses.

Now we could make a convention that Apps use to simplify this so that things go smoothly. Procedure below would be done by the Apps and not manually although it could be.

  • seller asks for payment
  • 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 and checks all sent ok
  • The buyer changes ownership of the “wallet” data structure to the seller
    • NOTE: at this time the buyer still technically owns the coins since they have the private key of that ID and the seller does not have the private key
  • The buyer sends the private key of that ID to the seller
    • NOTE: the buyer can still spend those coins so the sale is not complete
  • The seller then uses the “wallet” data to know the addresses of the coins and uses the private key of the ID to transfers those coins to an ID that only they know the private key of. (obviously this could be done sometime later)
  • The “wallet” data structure used for the sale is now discarded since it is of no use.
  • The sale is now complete
    • while the sending of multiple coins is not atomic, it did follow a protocol and the buyer had full control of the coins in case they had problems sending (eg not enough coins, technical errors, etc).
    • sale was only complete once the seller moved the coins from that temporary ID to their controlled ID. This is akin to the seller taking the cash from the buyer and putting it into their till (or pocket)

#37

Are not we complicating the problem a lot?

If we want to ensure that the seller receives the correct amount, would not it be sufficient to postpone the notification of the transaction until the buyer assures that all transfers of ownership are complete?

  • Seller asks for payment
  • The buyer send the orders of ownerships transfers (maybe with a transfer ID) but without communicate to seller
  • The buyer check that all transfer are correct, if not resend the fail transfers until fulfil the total.
  • When done send the information to the seller (more exactly to the Datamanagers of the seller who will show this payment on his wallet).

All this process can be automated in the wallet itself without the user having to worry.


#38

The point of the atomic transaction for multiple coins question is that if the buyer cannot send all the required coins, how can they get back the ones they sent. They would have to rely on the receiver sending the incomplete amount back.

My method above means that the buyer is in control until all coins are moved and the seller then only has to move the coins to their desired ID.

For instance if we went the simple way as per your suggestion

  • buyer thinks they have 1100 coins and the sale price is 1000 coins
  • buyer sends out coins
  • but some issue occurred because the buyer was also sending out 101 coins to another person using perhaps another wallet app.
  • the buyer mistakenly thought it was only 100 coins being sent by the other app and not 101.
  • because of the overlap and time required to send the 101 coins the other app still displayed that there is more than 1000 coins.
  • as the 1000 coins are being sent the other app completed the sending of 101 coins and the app sending the 1000 coins can only send 999 coins
  • Yes I know using 2 apps at basically the same time to send coins is not happening all the time, but it does illustrate one scenario where there is a problem

So how does the buyer get back the coins actually sent when doing that purchase requiring 1000 coins?


#39

It is much more likely that the buyer will get confused when typing and send an incorrect amount, or send it to a different address, or change the destination and the total of two different purchases or other possible human failures.

The network can not solve all these cases and the buyer and the seller must agree on a solution.


#40

Atomic transfers of multiple coins would solve it. Also the procedure built into the wallet apps would solve it. So why not explore possibilities. I am sure there are other solutions.