Change Contracts using Atomic Transfers

[paperThin]

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.

So you agree that the receiver cannot use the received funds to make change? A and B funds cannot be used to make C and D change?
So my original point was that the receiver could possibly NOT have enough change in their possession to make this method work.

 

[oblox]

So you agree that the receiver cannot use the received funds to make change? A and B funds cannot be used to make C and D change?
So my original point was that the receiver could possibly NOT have enough change in their possession to make this method work.

No, I'm saying you should be able to:

I (address A) want to buy something from you for 8 DRK. I send you 10 DRK to your address (address B) and no change comes back to me (A) in that block for that tx. In the next block or however many blocks, you (B) send 2 DRK to address C (which happens to belong to me) in a new tx. I get my change back and there shouldn't be a link to us. It should be no different than you deciding to send my received funds to anyone else other than me from a block chain glance. That second tx in theory is no different than tx 1 from a starting point. How you (address B) knows to send to my fresh change address C in a new tx is unknown to me.

I guess, what am I missing here in terms of linkages this way?

 

[moli]

So you agree that the receiver cannot use the received funds to make change? A and B funds cannot be used to make C and D change?
So my original point was that the receiver could possibly NOT have enough change in their possession to make this method work.

I'm thinking this is all digital, not paper money, so the receiver sure does have change, but the thing is, like Evan said, "the merchant must have a daemon running for it to work." And I'm not sure if merchants like to do this for DRK.

 

[oblox]

I'm thinking this is all digital, not paper money, so the receiver sure does have change, but the thing is, like Evan said, "the merchant must have a daemon running for it to work." And I'm not sure if merchants like to do this for DRK.

I don't agree a second daemon running being the way to go. It has to be in the client (qt) or daemon (darkcoind) as is. Further, this whole thing seems to disrupt instantx, not to mention leaving a security issue with the receiver needing to have their wallet unlocked just to allow that second tx to send.

 

[moli]

I don't agree a second daemon running being the way to go. It has to be in the client (qt) or daemon (darkcoind) as is. Further, this whole thing seems to disrupt instantx, not to mention leaving a security issue with the receiver needing to have their wallet unlocked just to allow that second tx to send.

I don't think depending on the receiver to return your change would work either, unless there's something I don't know or don't understand with this new plan. Digital cash is not quite like paper cash, so I'm not sure how this can work.

 

[darkwing]

So you agree that the receiver cannot use the received funds to make change? A and B funds cannot be used to make C and D change?
So my original point was that the receiver could possibly NOT have enough change in their possession to make this method work.

That's how I see it.. I love the idea of the contracts. But will exchanges implement this? And for merchants does having a daemon running expose you at all?

And as a retailer if someone breaks a high value DRK denomination (got change for 500?) they will have to have huge amounts of denominated funds to pay out the change.
And if they run out, they can no longer accept payments? Also what happens if they need change?

*edit* sorry to rant.. just not sure or not understanding.

On the plus side imagine you could use these contracts for things other than drk.

So I'll give you 10 DRK you give me 5 BTC

 

[paperThin]

No, I'm saying you should be able to:

I (address A) want to buy something from you for 8 DRK. I send you 10 DRK to your address (address B) and no change comes back to me (A) in that block for that tx. In the next block or however many blocks, you (B) send 2 DRK to address C (which happens to belong to me) in a new tx. I get my change back and there shouldn't be a link to us. It should be no different than you deciding to send my received funds to anyone else other than me from a block chain glance. That second tx in theory is no different than tx 1 from a starting point. How you (address B) knows to send to my fresh change address C in a new tx is unknown to me.

I guess, what am I missing here in terms of linkages this way?

Yes... you are missing something... the 2 DRK cannot be sourced from the original 10 DRK in this transaction or any future transaction. It must come from another address completely different. Otherwise if you looked at the blockchain you would have the "trail of bread crumbs" (Shown below)

1. Address B receives funds (10 DRK)
2. Next block or other block in the future
3. Address B sends funds to new Address D (How this address is know is a question we both have)
4. Now the original buyer has their change in address D. If they spend D down the road, it links them to the original 10DRK transaction.

but if in step 3, the "seller" uses a new and different address (ie address "C" sending to "D", then there is no link to "A" or "B"

If you just don't get what I am saying... that's fine. Either I'm crazy or I just can't explain it right. I will be curious how the issues that have come up will be solved!

 

[illodin]

You can denominate large change just like other funds. If you have 100 DRK denomination, and wanna send 15 DRK, you will get 85 DRK back as a change. So you can denominate that normally to 8x10 + 5x1. This problem stems from the change being too small (i.e. less than 2 DRK or so), which can't be combined with other funds and it can't be denominated either because it would cause bloat, right?

If this proposed system would be used, shouldn't it be used only for the remainder change after the smallest possible denomination?

But if this system would not be used, and the change would be anonymized normally (separately from normal funds of course), we'd need smaller denominations, which would cause bloat. But, what if the denominations would be for example 500, 100, 10, 5, 1, 0.5, 0.25, 0.1, 0.05, 0.025, 0.01? This would make the time it takes to find others to mix with longer, however it would lessen the bloat if we would denominate a change of 0.78 DRK it would generate 0.5 + 0.25 + 3x0.01 = 5 inputs instead of 7x0.1 + 8x0.01 = 15 inputs.

I just think a solution with a bit more bloat vs a system that can't work imo is better.

 

[Ryan Taylor]

Maybe I'm not understanding this, so could someone explain this... Why can't the sender's wallet just categorize any change as non-anonymized funds? Imagine the following scenario.

Initial setup: User has set 100 DRK as anonymous (and that 100 DRK has gone through the anonymization process) and 200 DRK total in their wallet
Step 1: User sends 7.50 DRK through Darksend to Merchant address
Step 2: Wallet uses anonymized funds to pay (say for this example a 10 DRK anonymized denomination), breaking the 10 DRK into 7.5 and 2.5 and sending the 7.5 to Merchant
Step 3: The wallet reclassifies the remaining 2.5 DRK to be non-anonymized funds
Step 4: The wallet is now showing only 90 DRK anonymized, and initiates anonymization process (which could prioritize "change" to be anonymized first) for additional 10 DRK
Step 5: The wallet re-anonymizes the 2.5 DRK plus an additional 7.5 DRK, returning a new 10 DRK denomination which has been through at LEAST two rounds or more depending on the wallet settings. If ever spent, the merchant would have no way of knowing who is spending it.

By simply treating / reclassifying any change as no longer anonymous, the users should be well aware that they are spending non-anonymous money if they ever spend the change without anonymizing it first. You could even have a higher-level protection in the form of an additional warning that displays "This transaction includes change from a previous transaction that has NOT been anonymized. The recipient of the previous transaction that resulted in the change will be able to identify you as the sender of the current transaction unless you use anonymous funds. Enter your password again if you understand these risks and wish to continue with the transaction anyway."

Does this solve the change problem? Or is there something I'm not considering?

 

[oblox]

Yes... you are missing something... the 2 DRK cannot be sourced from the original 10 DRK in this transaction or any future transaction. It must come from another address completely different. Otherwise if you looked at the blockchain you would have the "trail of bread crumbs" (Shown below)

1. Address B receives funds (10 DRK)
2. Next block or other block in the future
3. Address B sends funds to new Address D (How this address is know is a question we both have)
4. Now the original buyer has their change in address D. If they spend D down the road, it links them to the original 10DRK transaction.

but if in step 3, the "seller" uses a new and different address (ie address "C" sending to "D", then there is no link to "A" or "B"

If you just don't get what I am saying... that's fine. Either I'm crazy or I just can't explain it right. I will be curious how the issues that have come up will be solved!

Ah, I knew I was missing something simple. I guess you're right, you cannot assume that the change back address that we both are unsure how it is given is funded from funds already in the wallet even if there would be enough excess from the initial transaction. So you could run into issues where the receiver doesn't have the funds available to send for change. You could solve this by forcing the excess to be anon'd through darksend before going back but then you are prolonging the time it takes for the initial sender to get their rightfully owned change back, right? Further, you still run into issues than with change back sourced from funds under the denomination threshold.

 

[darkwing]

Maybe I'm not understanding this, so could someone explain this... Why can't the sender's wallet just categorize any change as non-anonymized funds? Imagine the following scenario.

Initial setup: User has set 100 DRK as anonymous (and that 100 DRK has gone through the anonymization process) and 200 DRK total in their wallet
Step 1: User sends 7.50 DRK through Darksend to Merchant address
Step 2: Wallet uses anonymized funds to pay (say for this example a 10 DRK anonymized denomination), breaking the 10 DRK into 7.5 and 2.5 and sending the 7.5 to Merchant
Step 3: The wallet reclassifies the remaining 2.5 DRK to be non-anonymized funds
Step 4: The wallet is now showing only 90 DRK anonymized, and initiates anonymization process (which could prioritize "change" to be anonymized first) for additional 10 DRK
Step 5: The wallet re-anonymizes the 2.5 DRK plus an additional 7.5 DRK, returning a new 10 DRK denomination which has been through at LEAST two rounds or more depending on the wallet settings. If ever spent, the merchant would have no way of knowing who is spending it.

By simply treating / reclassifying any change as no longer anonymous, the users should be well aware that they are spending non-anonymous money if they ever spend the change without anonymizing it first. You could even have a higher-level protection in the form of an additional warning that displays "This transaction includes change from a previous transaction that has NOT been anonymized. The recipient of the previous transaction that resulted in the change will be able to identify you as the sender of the current transaction unless you use anonymous funds. Enter your password again if you understand these risks and wish to continue with the transaction anyway."

Does this solve the change problem? Or is there something I'm not considering?

The change would have to be unspendable (until redenominated) as spending it in the future would expose the previous transaction.

 

[thelonecrouton]

What about proof of burn for the change? Gets logged by the MNs and all burners get whatever has been burned back from freshly minted blocks. This wouldn't have to be deflationary, extra DRK could be minted each block to cover it.

Getting a bit radical... :tongue:

In fact, if every tx was burned and the receiver instead got freshly minted DRK, privacy would be perfect as no DRK would ever have any history. :grin:

 

[oblox]

The change would have to be unspendable (until redenominated) as spending it in the future would expose the previous transaction.

Add a 0.10 denomination and then implement masternode locks on change under denomination limits until it reaches a point to be mixed? I feel like this idea was already mentioned in the dead change thread.

 

[oblox]

What about proof of burn for the change? Gets logged by the MNs and all burners get whatever has been burned back from freshly minted blocks. This wouldn't have to be deflationary, extra DRK could be minted each block to cover it.

Getting a bit radical... :tongue:

In fact, if every tx was burned and the receiver instead got freshly minted DRK, privacy would be perfect as no DRK would ever have any history. :grin:

I don't like the idea of messing with the block rewards again but it is an interesting idea for a new coin. One burn address for the network, the receiver automatically sends their received tx to the burn address. The network scans the burn address for amounts and from addresses, sums the total amount burned and adds that to the normal block reward with the block found sending the fresh coins to the from addresses found at the burn address. Although I believe this would be very bloated. Probably something obvious missing here as well in terms of privacy but it sounded cool.

 

[thelonecrouton]

I don't like the idea of messing with the block rewards again but it is an interesting idea for a new coin. One burn address for the network, the receiver automatically sends their received tx to the burn address. The network scans the burn address for amounts and from addresses, sums the total amount burned and adds that to the normal block reward with the block found sending the fresh coins to the from addresses found at the burn address. Although I believe this would be very bloated. Probably something obvious missing here as well in terms of privacy but it sounded cool.

Solves the change problem, pretty sure it yields almost perfect privacy with fresh addresses each time, don't see it being bloaty at all, possibly the opposite, and we could still use the MN network for InstanTX's faster than the blocktime. Plus we could call it the Eschaton Protocol.

OK, I'll stop now. :tongue:

 

[Ryan Taylor]

Add a 0.10 denomination and then implement masternode locks on change under denomination limits until it reaches a point to be mixed? I feel like this idea was already mentioned in the dead change thread.

What downsides are there, then? The only mentioned so far:
1) You might need to wait for more funds to anonymize (but you have to do this anyway, so not really much of a "downside" vs. transactions without change)
2) Users could expose themselves, but only after being warned and deciding they are OK with it (for example, I might be fine letting Target.com know that in a later transaction I bought something from Walmart.com and override the warning if I don't feel like waiting for enough anonymous funds, but I might NOT be OK with spending change from a transaction with my wife at the casino)

Anything else? Basically, only spend anonymous funds and you remain anonymous. Sounds simple enough to me... this seems like a non-issue "red herring" to me, at least based on the objections so far.

 

[thelonecrouton]

I think the bloat issue is overblown. Increasing the denomination resolution to whatever level is sensible given (hopefully) increasing DRK price isn't going to drastically increase the size of the blockchain beyond the amount (hopefully) adoption will anyway.

Is there such a thing as a purely deterministic/procedural blockchain? If block (x-1) could be recreated perfectly from block x, we wouldn't need to maintain store a blockchain at all.

 

[paperThin]

Ah, I knew I was missing something simple. I guess you're right, you cannot assume that the change back address that we both are unsure how it is given is funded from funds already in the wallet even if there would be enough excess from the initial transaction. So you could run into issues where the receiver doesn't have the funds available to send for change. You could solve this by forcing the excess to be anon'd through darksend before going back but then you are prolonging the time it takes for the initial sender to get their rightfully owned change back, right? Further, you still run into issues than with change back sourced from funds under the denomination threshold.

The person making change can't fix the issue by doing "darksend denominates" (DSD is that how we are abbreviating?) using the payment from the buyer. Sure, that would work with the whole numbers, but it does not handle the fractional DRK. The whole numbers are not a real big issue anyway, because the buyer can premix whole numbers to exactly 1DRK above the cost. (ie 12.75 can be sent as 13DRK, so if he prepares his payment, he only has to wait for a fractional DRK.)
None of the original payment can be used to make fractional change (it is the fractional change that makes "bread crumbs")

As I write this, I realize that this A,B then C, D does not fix anything (see example)

Buyer: Joe
Seller: QuestionableProductsSeller (QPS)

• Joe buys a butterfly knife from QPS for 8.25 DRK
• Joe sends 9 DRK to QPS
  • All new addresses used for this example
    
  • (This step is A -> B)
  • Joe's 9 DRK were run through Darksend Denominate(DSD) 20x
• QPS receives 9 DRK to his address B
• A new block is found... time has elapsed
• QPS sends Joe 0.75 DRK from a new and separate address
  • (This step is C -> D)
    
  • This is less than 1 DRK, so it would be impossible to DSD
  • QPS could not have DSD on this unless it came from a whole 1.0 DRK
  • Joe will not be able to DSD since it is fractional change
  • Joe should not mix this with other purchases if he does not want future trouble (dead change here)
• If QPS used 1.0 DRK DSD 20x to make the payment to Joe...
  • then QPS would have 0.25 "dead change" that will link future purchases.
• If QPS used exact change 0.75 DRK to make the payment to Joe...
  • then it was not DSD at QPS and not possible to DSD when received by Joe
• We have a direct link from QPS to Joe
  • Even if both Joe and QPS did their best to be "careful", there is no method to stay private
  • Of course, donating the change is still a valid method...

If I am wrong here, please point out the flaw... Aswan, care to comment?

Zombies!!!

 

[David]

I think the bloat issue is overblown. Increasing the denomination resolution to whatever level is sensible given (hopefully) increasing DRK price isn't going to drastically increase the size of the blockchain beyond the amount (hopefully) adoption will anyway.

Is there such a thing as a purely deterministic/procedural blockchain? If block (x-1) could be recreated perfectly from block x, we wouldn't need to maintain store a blockchain at all.

I agree with this. Darkcoin's MN network should be sufficient to store and serve the blockchain even without any other nodes running on people's PCs, etc. We currently have 1230 MNs, all serving the complete blockchain, and Evan's target is 2,000 - 3,000 within the next year. So I'm not really worried about bloat unless it's extreme (like the CN currencies).

Bitcoin has a market cap that's 431x as large as Darkcoin and does fine with 6766 full nodes (https://getaddr.bitnodes.io/).

 

[illodin]

Just make the denoms 500, 100, 10, 5, 1, 0.5, 0.25, 0.1, 0.05, 0.025, 0.01 (and even 0.005, 0.0025, 0.001) and get this over with imo. Deal with bloating later if needed - "summary blocks", mini-blockchain, or some other form of pruning that is yet to be discovered.