Change Contracts using Atomic Transfers

eduffield

Core Developer
Mar 9, 2014
1,084
5,320
183
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:

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
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.
 

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
There is no spoon spork change. :tongue:

edit: what happens when B doesn't have enough DRK to supply the 'change' to A?
 

eduffield

Core Developer
Mar 9, 2014
1,084
5,320
183
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.
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.
 

Propulsion

The buck stops here.
Feb 26, 2014
1,008
468
183
Dash Address
XerHCGryyfZttUc6mnuRY3FNJzU1Jm9u5L
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?
 

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
What happens when the seller shuts down the client before the change contract is paid?

How would it be enforced?

Is it cheatable?
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."
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
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.
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?
 
  • Like
Reactions: drkhouse

cryptoyogi

New Member
Jun 9, 2014
18
18
3
For those of us less technologically advanced, is this very important or a technological breakthrough?
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
For those of us less technologically advanced, is this very important or a technological breakthrough?
It solves an important issue surrounding maintaining privacy in Darksend, the core feature of this coin.
 

darkchild

Member
Sep 20, 2014
76
193
73
Proxima Centauri
www.dashnodes.com
For those of us less technologically advanced, is this very important or a technological breakthrough?
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.
 
  • Like
Reactions: tungfa

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
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..
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.
 

g8F98FF3gjafogj4

Well-known Member
Foundation Member
Apr 8, 2014
151
84
188
What would happen if you wanted to anonymously send funds to someones tip address but they didn't have a daemon running?
 

illodin

Member
Apr 26, 2014
122
71
78
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)
 

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,639
3,537
1,183
Let's imagine that liquidity provider is a vendor too.... who sells "service" for 0.1 DRK...
 

Minotaur

Well-known Member
Foundation Member
Apr 7, 2014
452
1,079
263
Let's imagine that liquidity provider is a vendor too.... who sells "service" for 0.1 DRK...
Can you explain a little bit better what happens if the receiver does not have the wallet running when the coins are Darksent?
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
Can you explain a little bit better what happens if the receiver does not have the wallet running when the coins are Darksent?
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.
 

TaoOfSatoshi

Grizzled Member
Jul 15, 2014
2,819
2,623
1,183
Dash Nation
www.dashnation.com
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!
 

aaxx1503

Active Member
Feb 28, 2014
113
106
93
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?
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
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?
Well... in every case, they would because the person sending would be "overpaying".
 

JGCMiner

Moderator
Moderator
Jun 8, 2014
364
217
113
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)
I think your second and third points are not really issues. As Oblox says above, the sender is overpaying and the receiver signs a contract to return the excess. There should be no problem sending to a wallet with 0 balance and multiple iterations to get the exact change are not necessary as I understand it.

As for the first point... I wonder if a random masternode can be selected to lock the funds in escrow for say, 1 week worth of blocks -- such that, if the reciever runs the wallet software at any point during that window he receives the transaction. Else, the funds are released back to the sender when the window closes.
 

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
Well... in every case, they would because the person sending would be "overpaying".
But then you're back to square one - isn't the point of this that the 'change' you get back isn't your own? Therefore not really change at all. Therefore avoiding the change problem?
 
  • Like
Reactions: illodin

crowning

Well-known Member
May 29, 2014
1,415
1,997
183
Alpha Centauri Bc
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
Some random early-morning thoughts:

  • What if (for whatever reason) (A) never makes step 3? Or (B) step 4? Are the funds kinda locked and how are they unlocked? Timeout perhaps?
  • Also, what happens when "Evil-A" invests the money to make some kind of "Contract-Flooding"? Thousands of unfinished contracts.
  • And what if (B) hasn't the funds for the change? Will the contract be cancelled?
 

darkwing

Active Member
Apr 8, 2014
149
110
103
Forgive me if I'm missing something key.. but would sending the correct amount to yourself not solve the problem? So person wants to send 1 drk needs 9 drk change. Client sends anon funds to self splitting 1 and 9 into separate addresses. While both link back to the original 10 drk address it is anonymous so what can be gathered? 1 Drk is then sent to the merchant (still only links back to an anon address) and the 9 change will have to be reanonymized. Or is that how it works now?

These atomic contracts I imagine would be fantastic/necessary for instantX but is the above not a viable offline option?
 
Last edited by a moderator:

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
Forgive me if I'm missing something key.. but would sending the correct amount to yourself not solve the problem? So person wants to send 1 drk needs 9 drk change. Client sends anon funds to self to self splitting 1 and 9 into separate addresses. While both link back to the original 10 drk address it is anonymous so what can be gathered? 1 Drk is then sent to the merchant (still only links back to an anon address) and the 9 change will have to be reanonymized. Or is that how it works now?

These atomic contracts I imagine would be fantastic/necessary for instantX but is the above not a viable offline option?
Have the client automatically generate the exact 'chunk' prior to sending it, so there's no change. I like it. :) At least keeps the sub-denom amounts in wallet.
 
Last edited by a moderator:
  • Like
Reactions: drkhouse

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
But then you're back to square one - isn't the point of this that the 'change' you get back isn't your own? Therefore not really change at all. Therefore avoiding the change problem?
The difference is that it's not coming back in the same tx. This leads then to the problem of looking at timestamp to match up change, but most likely fixed with a random delay in returning the second tx.
 

thelonecrouton

Well-known Member
Foundation Member
Apr 15, 2014
1,135
813
283
The difference is that it's not coming back in the same tx. This leads then to the problem of looking at timestamp to match up change, but most likely fixed with a random delay in returning the second tx.
What connects the two transactions? There's nothing on the blockchain to indicate they have anything to do with each other. You could point at any two transactions and claim some link, but where's the evidence?

edit: I am assuming the contract specifies sending the 'change' to an address other than the spent-from one...?
 

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
I also have some follow up questions to the ones that have been left unknown:

1. Why does there even need to be a contract or a daemon open? Why can't at the time of you send, the client automatically rounds up to the nearest denomination, sends the whole lot over and then on receival, the masternode locks what should be change, setting it aside for a send back in a fresh tx at a random (say within 3-6 blocks). Seems in both cases, anyone with a passphrase on their wallet will run into issues of needing to be around to unlock it for the second tx back acting as change? Both ideas (mine and Evan's) seems to counter the idea of going in the direction of Instantx if there are more steps involved in setting the transaction up, whether it be introducing a timer for when to release the funds or human interaction for prompting a passphrase for the secondary sendback.

2. How is party B knowing where to send the tx back to? Obviously it needs to be a fresh address generated in wallet A, so how is the key being passed to B?
 

drkhouse

Member
Nov 22, 2014
79
19
48
Have the client automatically generate the exact 'chunk' prior to sending it, so there's no change. I like it. :) At least keeps the sub-denom amounts in wallet.
I love Evan's work. But on this change thing, I am pretty sure most merchant will never have a daemon open.

Based on this, I like this idea more.
 
Last edited by a moderator:

oblox

Well-known Member
Aug 6, 2014
1,032
537
183
If we assume all anon transactions are this new smart contact method, aren't we shooting ourselves in the foot for future security and features (instantx)? The change is the problem so the fix would need to be on all the time when it comes to tx's requiring anonymity. If you implement smart contracts, there needs to be conditions involved with their usage, example, time involved before reverting to one of the secondary cases. If you start having time involved, what good is instantx if x number of minutes need to go by anyway? From a security standpoint, the tx to a fresh address back to A would need to have the user have the wallet unlocked. Then there is the whole issue of the masternode still knowing where party B is going to send "change" A in the first place.