Change Contracts using Atomic Transfers

[JGCMiner]

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... 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?

 

[crowning]

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]

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?

 

[thelonecrouton]

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.

 

[oblox]

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]

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]

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]

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.

 

[oblox]

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.

 

[eduffield]

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?

This is exactly how change works as default in the client.

A -> B | C

A = 10DRK (source)
B = 1DRK (payment)
C = 9DRK (change)

That's the transaction you're describing. The problem is that you can B and C came from A. So later on when C is combined with other funds in the wallet you can follow the anonymous transaction forward to those funds.

C + D -> E (Payment) | F (change)

C = Change from previous example
D = Older funds in your wallet (linked to cryptsy or something else)
E = Payment
F = Change

If D knows you identity now, they also know you bought B previously.

----------------------------------

Here's how Change Contracts fix that

- payment

A -> B (User A - over pays)

A = 10DRK (source)
B = 10DRK (payment, desires to pay 1DRK)

- change

C -> D | E
C = 15DRK (merchant)
D = 9DRK (payment to user A)
E = 6DRK (change back to himself)

In this situation D has no link with B, so when it's combined later with pre-existing funds it doesn't give up anonymity at all.

 

[oblox]

This is exactly how change works as default in the client.

A -> B | C

A = 10DRK (source)
B = 1DRK (payment)
C = 9DRK (change)

That's the transaction you're describing. The problem is that you can B and C came from A. So later on when C is combined with other funds in the wallet you can follow the anonymous transaction forward to those funds.

C + D -> E (Payment) | F (change)

C = Change from previous example
D = Older funds in your wallet (linked to cryptsy or something else)
E = Payment
F = Change

If D knows you identity now, they also know you bought B previously.

----------------------------------

Here's how Change Contracts fix that

- payment

A -> B (User A - over pays)

A = 10DRK (source)
B = 10DRK (payment, desires to pay 1DRK)

- change

C -> D | E
C = 15DRK (merchant)
D = 9DRK (payment to user A)
E = 6DRK (change back to himself)

In this situation D has no link with B, so when it's combined later with pre-existing funds it doesn't give up anonymity at all.

I have questions in this thread as it relates to this, namely timeliness (and how it will relate to instantx implementation), security, and privacy. Please answer at your leisure so I can get a better understanding if this actually can solve the issue.

EDIT: Come to think of it, there are a lot of valid questions in here that should be answered. Better to get the logistics out ahead of time before coding starts.

 

[darkwing]

This is exactly how change works as default in the client.

A -> B | C

A = 10DRK (source)
B = 1DRK (payment)
C = 9DRK (change)

That's the transaction you're describing. The problem is that you can B and C came from A. So later on when C is combined with other funds in the wallet you can follow the anonymous transaction forward to those funds.

C + D -> E (Payment) | F (change)

C = Change from previous example
D = Older funds in your wallet (linked to cryptsy or something else)
E = Payment
F = Change

If D knows you identity now, they also know you bought B previously.

I understand that I think I wasn't clear in my post.

I'm saying add an extra transaction if change is required.
Splitting the anon funds into the required amounts as a payment to self. Then send the exact amount to the retailer. That way the retailer doesn't have to issue change. And the full amount doesn't have to go over and come back.


A = 10DRK (source)
B = 1DRK (payment to self) ---> once confirmed pay to D = 1DRK payment to merchant
C = 9DRK (change - payment to self)

Could the change not be locked in a separate balance? Requires denomination?

 

[paperThin]

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.

Maybe this helps explain...

Your idea moves the problem, but it is still there. The blockchain would show the exact change made ahead and the other part. i.e. if price was 3 that you made from a 10, so you split 7 and 3 and spend the 3. Now there is a permanent connection to the 7 even though you did it ahead of time. If it was a whole number "7" you could re-darksend denominate so you could spend again. Chances are that it will not be a whole number.

 

[paperThin]

I have questions in this thread as it relates to this, namely timeliness (and how it will relate to instantx implementation), security, and privacy. Please answer at your leisure so I can get a better understanding if this actually can solve the issue.

EDIT: Come to think of it, there are a lot of valid questions in here that should be answered. Better to get the logistics out ahead of time before coding starts.

Here's a question... If the the receiver uses the original amount (ie 10 DRK) to make the change (9 DRK), then there will be a link in the blockchain. (original problem still present) They should use a different address for the change which would require "other funds" in the wallet... separate from the receiving DRK.

So you could have a problem with the receiver not having enough change, right?

 

[oblox]

Here's a question... If the the receiver uses the original amount (ie 10 DRK) to make the change (9 DRK), then there will be a link in the blockchain. (original problem still present) They should use a different address for the change which would require "other funds" in the wallet... separate from the receiving DRK.

So you could have a problem with the receiver not having enough change, right?

They would be making "change" from the overage from my understanding so there shouldn't be an instance where the receiver doesn't have enough funds to make change. The receiver should obviously send to a fresh address that the sender created... how the receiver actually knows this address is unknown (Evan hasn't answered). Then it seems you are going down the road of masternodes knowing the send-back address. This all then falls on the receiver leaving the wallet unlocked after receival to be able to send the new tx out (security risk).

 

[paperThin]

They would be making "change" from the overage from my understanding so there shouldn't be an instance where the receiver doesn't have enough funds to make change. The receiver should obviously send to a fresh address that the sender created... how the receiver actually knows this address is unknown (Evan hasn't answered). Then it seems you are going down the road of masternodes knowing the send-back address. This all then falls on the receiver leaving the wallet unlocked after receival to be able to send the new tx out (security risk).

Right, but they can't use the "overage" because that keeps the original problem... A, B relating to C, D. C and D have to be "fresh and separate".
If they send to a new address, it still shows that it came from "A" which links it all together again.

 

[oblox]

Right, but they can't use the "overage" because that keeps the original problem... A, B relating to C, D. C and D have to be "fresh and separate".
If they send to a new address, it still shows that it came from "A" which links it all together again.

It would be fresh and separate in the sense that it's not included in the same block. How would this be any different than someone sending funds and then the ending party deciding to buy something from someone else (with the address happening to belong to the initial sender) a block or so later?

 

[paperThin]

It would be fresh and separate in the sense that it's not included in the same block. How would this be any different than someone sending funds and then the ending party deciding to buy something from someone else (with the address happening to belong to the initial sender) a block or so later?

Of course, this is still the "dead change" issue, right? We are on the same page there, right?

If they spend it with someone else... that is fine, or if randomly it goes around and comes back to the original user, that's fine too.

The problem we are trying to solve is for the buyer to be able to spend their change without that change having any connection to the original transaction. The "A,B then C, D" method does solve the dead-change problem. However, C,D must not have any connection (address-wise) to A or B.
(I agree on your other point... how does the seller know the new address? How is it passed to them securely and without trace?)

Good discussion!

 

[oblox]

Of course, this is still the "dead change" issue, right? We are on the same page there, right?

If they spend it with someone else... that is fine, or if randomly it goes around and comes back to the original user, that's fine too.

The problem we are trying to solve is for the buyer to be able to spend their change without that change having any connection to the original transaction. The "A,B then C, D" method does solve the dead-change problem. However, C,D must not have any connection (address-wise) to A or B.
(I agree on your other point... how does the seller know the new address? How is it passed to them securely and without trace?)

Good discussion!

Correct, it all comes back to the dead change issue. In theory, by over paying, the initial tx has no change to come back to be "dead". Then the second tx (new block) that contains the change goes to a fresh address (which from a block chain glance could be anyone) that belongs to the initial sender. This should remove all linkages. The problem I see is passing in the original tx the newly generated change address to the receiver in a way that doesn't allow any linkages. If done by masternodes, then a rogue masternode can link.