Change Contracts using Atomic Transfers

eduffield

eduffield

Core Developer
One of the most challenging parts of making an anonymous currency is dealing with change. After Darksend completes mixing on multiple sessions, a user has anonymous funds, but it's possible that after a purchase the change from a purchase could be recombined with that users funds. This is a type of linkage called "forward linking".

In the real world when you buy something from a merchant, you would give $100 to the merchant, then the merchant would provide you $4 in change. In the world of crypto, that $100 is split into $96 and $4. Afterward, you can always see they were once the same $100.

So what if you could make a crypto-currency that pays change just like the real world?

Change Contracts
User A wants to buy a laptop from Merchant B for $96 (in dollars to make it easier).

1: User (A) publishes a message to Merchant (B), saying I'll pay you $100 if you pay me back $4
2: (B) signs this message, returning it to (A). This is the contract.
3: A makes TX1 (pay $100 to B, only good if B pays A). A provides TX1 to B
4. B makes TX2 (pay $4 to A, only if A pays B). B provides TX2 to A
5. A & B make TX3 (A pays B $96) and TX4 (B pays A $4)
6. A & B publish TX3 & TX4

If TX3 & TX4 are both published, then the change went through.
If either is not published A or B can publish TX1 or TX2 to ensure they receive the money.

TX1 & TX2 will link the payments from the CScript, so this is not ideal. But it ensures the system remain trustless.

With change contracts, you'll receive money in change that has absolutely no relationship to the money you paid. This will be done in two separate, unlinkable transactions. Due to this happening regularly on the network, a high quality mixing of funds will take place, making it much like traditional cash.

This will be done at a protocol level, almost completely automatically. As a merchant, You'll receive "change contracts" and approve them, this will complete steps 1 to 4 automatically. However, once you sign and publish TX1 and TX2, there is no way to back out, so a merchant must make sure the payment is correct for the mechanize being purchased.

After all is said and done, this is akin to a vendor paying you change from their drawer. Surely a huge improvement in the anonymity of Darkcoin.



Thanks to UdjinM6 for helping out with the concept!
 
Last edited by a moderator:
Just so I am following logic, in step 3, A actually pays B 100, not the direct 96. The rest of it makes sense then. Does this automatically then become the default standard for change--remove change from the transaction for any overages on approval from the merchant or is it only for DS transfers? So if you wanted to buy something, how do you initially send a change contract? Does that just happen from communication outside of DS? I'd love to hear more on this because at first glance, it seems like it solves linkages.

Finally, the last logical question would be a timeframe on implementing this change? I'm assuming it's a spork with enforcement back off.
 
There is no spoon spork change. :tongue:

edit: what happens when B doesn't have enough DRK to supply the 'change' to A?
 
oblox said:
Just so I am following logic, in step 3, A actually pays B 100, not the direct 96. The rest of it makes sense then. Does this automatically then become the default standard for change--remove change from the transaction for any overages on approval from the merchant or is it only for DS transfers? So if you wanted to buy something, how do you initially send a change contract? Does that just happen from communication outside of DS? I'd love to hear more on this because at first glance, it seems like it solves linkages.
Click to expand...

Opps, you got it. At first I'll add it just for anon purchases, they'll go through a completely different set of protocol commands. But eventually, it should be used for everything. However, the merchant must have a daemon running for it to work.
 
What happens when the seller shuts down the client before the change contract is paid?

How would it be enforced?

Is it cheatable?

Edit: Is this the solution to the 'dead change' issue?
 
Propulsion said:
What happens when the seller shuts down the client before the change contract is paid?

How would it be enforced?

Is it cheatable?
Click to expand...
It should be atomic - (via MN transaction locks?) - whole deal either happens or not.

But: "If either is not published A or B can publish TX1 or TX2 to ensure they receive the money."
 
eduffield said:
Opps, you got it. At first I'll add it just for anon purchases, they'll go through a completely different set of protocol commands. But eventually, it should be used for everything. However, the merchant must have a daemon running for it to work.
Click to expand...
Is there anyway to embed it into the client (qt or darkcoind) so there isn't a separate daemon that needs to be ran?

Also, from the standpoint of the contract itself, how would the contract know what address (I'm assuming it generates a fresh address in A's wallet) to send the 4 drk to? Any linkages that can be used in this sort of communication?
 
cryptoyogi said:
For those of us less technologically advanced, is this very important or a technological breakthrough?
Click to expand...

This is pretty important because it mimics real world cash payments together with privacy, and guarantees that you do get your change in return. I'm not sure why you would want to pay $100 when you can just pay the $96 unless it was some kind of instant rebate purchase.

The more things we can do with the darkcoin wallet like this the more merchants darkcoin will attract.
 
darkchild said:
I'm not sure why you would want to pay $100 when you can just pay the $96 unless it was some kind of instant rebate purchase..
Click to expand...

Example numbers to make it easier to grasp. The change issue is (usually, but not always, maybe you only have a 100DRK lump to spend) one of small (sub 1DRK) amounts in practice, but is important because those small amounts can provide information about past transactions and thus compromise your privacy.
 
What would happen if you wanted to anonymously send funds to someones tip address but they didn't have a daemon running?
 
Cons:
  • receiver must have wallet running when you're sending the money
  • receiver must have $4 (the example) to send back to you
  • you must have $1 (assuming denoms are $1, $10, $100) to send back to him (this gets more complicated if you want to send $93: send $100, receive $10, send $5, receive $1 and $1)
 
Let's imagine that liquidity provider is a vendor too.... who sells "service" for 0.1 DRK...
 
UdjinM6 said:
Let's imagine that liquidity provider is a vendor too.... who sells "service" for 0.1 DRK...
Click to expand...

Can you explain a little bit better what happens if the receiver does not have the wallet running when the coins are Darksent?
 
Minotaur said:
Can you explain a little bit better what happens if the receiver does not have the wallet running when the coins are Darksent?
Click to expand...
Right now it sounds like the receiving party would need to first agree to taking over the amount and sending "change" back as a new tx. How this works is beyond me.
 
See, it's like I said in the dead change thread, you give Evan enough time, he WILL figure it out!

Thank you eduffield for taking the time to fully deal with this issue. This solution is loads better than the previous one. We will all benefit in the end!

No joke brother, you are the man!
 
That's a very interesting solution to the problem. Kudos to the entire dev team. Was there an answer to the "what if the person doesn't have enough change?" question?
 
aaxx1503 said:
That's a very interesting solution to the problem. Kudos to the entire dev team. Was there an answer to the "what if the person doesn't have enough change?" question?
Click to expand...
Well... in every case, they would because the person sending would be "overpaying".
 
You must log in or register to reply here.
Back
Top