Change Contracts using Atomic Transfers

moli said:
I thought this was about how your transactions can be de-anonymized and traced back to your origin address. No?
Click to expand...
I have to remind you Aswan reply :wink:
Aswan said:
.....
What I mean is that if a dead change never gets used, it's fine, but when it gets used in a transaction that transacts more than the amount of the dead change and therefore needs another output as input, not only that transaction, but also it's change gets linked to the parent transaction of the initial dead change.
If you combine 2 or more dead changes, all the purchases of all of their parent transactions get linked together.
Click to expand...
 
oblox said:
It has more to do with linking future purchases together with finding one's origin address a possible result.
Click to expand...
Then maybe user should only anonymize what he needs for each purchase and use all of that amount as a lump sump for that one-time purchase and be done over with ?
 
moli said:
Then maybe user should only anonymize what he needs for each purchase and use all of that amount as a lump sump for that one-time purchase and be done over with ?
Click to expand...
You would need to use coin control on the sends to make sure you are pulling the appropriate denominations that are already anon so no change comes back. If you send normally via a ds tx, you might pull a larger denom and end up with change back.
 
oblox said:
You would need to use coin control on the sends to make sure you are pulling the appropriate denominations that are already anon so no change comes back. If you send normally via a ds tx, you might pull a larger denom and end up with change back.
Click to expand...
Yes, that's what I would use and have been using all along. It would be nice to have a feature like "How would you want to break down your money? Would you like to have 50 of 1's and 20 of 10's as denominations?" Just more small denoms so users can have less change and might as well just go ahead to give the change as tips to merchants.
 
Another thing: Maybe we need to create another wallet with the Coin Control open up in users' face and be used in place of the drop down list for "Create Darksend Transaction".. so users have no problem to find it and know they need to choose the exact amount to send, with no change back. Problem solved!
 
I have no idea what else Evan is currently working on, but I'd rather get on with IX and other stuff than spend weeks overanylising this issue. Denominate down to 0.1 or 0.01, bloat be damned, we have time to deal with it if it ever gets to be a problem. What merchants are going to be selling anything in units of less than 0.01 anyway?

Stick a warning popup in the client if a user tries to spend linkable change. Maybe make the auto input choosing a little bit smarter. Move on.

edit: Also, what moli said - make the coin control thing more obvious, make it a routine part of the process. You open your guvpaper wallet, you choose which notes and coins to take out, same thing.
 
Last edited by a moderator:
thelonecrouton said:
I have no idea what else Evan is currently working on, but I'd rather get on with IX and other stuff than spend weeks overanylising this issue. Denominate down to 0.1 or 0.01, bloat be damned, we have time to deal with it if it ever gets to be a problem. What merchants are going to be selling anything in units of less than 0.01 anyway?

Stick a warning popup in the client if a user tries to spend linkable change. Maybe make the auto input choosing a little bit smarter. Move on.
Click to expand...
Denomination to 0.1 might be a good temporary solution actually. And I would suggest to pay everything smaller than 0.1 as a tx fee - this will be the cost of the bloat. We can always shift it when price goes up. And we were talking about eliminating 500 and 100 denoms anyway...
The only problem is user have to have enough of these denoms to combine into right amount. If you have 100 DRK anonymized and you want to pay 19.9 you'll need 1x10, 9x1 and 9x0.1. And every time you pay you need to have full set of smaller denoms. So for 5 payments by 19.9 you'll need 5x10, 45x1, 45x0.1. Now imagine you want to pay by 9.9 instead... When you do it ahead-of-time you never know how many of each denoms you'll actually need.
 
UdjinM6 said:
Denomination to 0.1 might be a good temporary solution actually. And I would suggest to pay everything smaller than 0.1 as a tx fee - this will be the cost of the bloat. We can always shift it when price goes up. And we were talking about eliminating 500 and 100 denoms anyway...
The only problem is user have to have enough of these denoms to combine into right amount. If you have 100 DRK anonymized and you want to pay 19.9 you'll need 1x10, 9x1 and 9x0.1. And every time you pay you need to have full set of smaller denoms. So for 5 payments by 19.9 you'll need 5x10, 45x1, 45x0.1. Now imagine you want to pay by 9.9 instead... When you do it ahead-of-time you never know how many of each denoms you'll actually need.
Click to expand...

Is it possible to allow users some control over this? If most of what I buy costs a few DRK, I'd rather have a lot of 1's, not so much of the 10's and 100's...
 
moli said:
Yes, that's what I would use and have been using all along.
Click to expand...
No you haven't, you spent inputs that were not anon. They were inputs that could be linked to earlier transactions. If you're referring to the example you posted earlier that is.
 
UdjinM6 said:
Denomination to 0.1 might be a good temporary solution actually. And I would suggest to pay everything smaller than 0.1 as a tx fee - this will be the cost of the bloat. We can always shift it when price goes up. And we were talking about eliminating 500 and 100 denoms anyway...
The only problem is user have to have enough of these denoms to combine into right amount. If you have 100 DRK anonymized and you want to pay 19.9 you'll need 1x10, 9x1 and 9x0.1. And every time you pay you need to have full set of smaller denoms. So for 5 payments by 19.9 you'll need 5x10, 45x1, 45x0.1. Now imagine you want to pay by 9.9 instead... When you do it ahead-of-time you never know how many of each denoms you'll actually need.
Click to expand...
No you don't have to have exact denoms. If you want to pay 19.9 you will just send 100 and get 80.1 back as a change. What would happen next is that you'd denominate that 80.1 to 8x10 + 0.1, and then start anonymizing that. The process could be even streamlined so that all those transactions would be made at the same time, i.e. 19.9 + 8x10 + 0.1
 
thelonecrouton said:
Is it possible to allow users some control over this? If most of what I buy costs a few DRK, I'd rather have a lot of 1's, not so much of the 10's and 100's...
Click to expand...
Hmmm... We'd better ask Evan eduffield I guess :) I'm not sure how this could be presented in UI though.
Something like that?
Code: 
Choose amount of DRK to anonymize:

       10     1    0.1
     [ 4 ] [ 14 ] [ 6 ]

You will anonymize 54.6 DRK

EDIT: slightly changed "UI" example to reflect "I want more 1's" situation ;)
 
LOL, we must drive Evan nuts. :tongue:

chicks.jpg
 
Last edited by a moderator:
thelonecrouton said:
I have no idea what else Evan is currently working on, but I'd rather get on with IX and other stuff than spend weeks overanylising this issue. Denominate down to 0.1 or 0.01, bloat be damned, we have time to deal with it if it ever gets to be a problem. What merchants are going to be selling anything in units of less than 0.01 anyway?

Stick a warning popup in the client if a user tries to spend linkable change. Maybe make the auto input choosing a little bit smarter. Move on.

edit: Also, what moli said - make the coin control thing more obvious, make it a routine part of the process. You open your guvpaper wallet, you choose which notes and coins to take out, same thing.
Click to expand...

I agree with Crouton that a bandaid can be placed on this issue by
  • lowering the denominate a little
  • Setting aside "dead change" so that the user can have a clear understanding that it should be kept separate unless they choose to compromise anonymity.
However, even if this is not Even's most pressing item, it is worth a discussion to look for a solid long term solution. Definitely worth discussing! If we come up with something that sounds like a solid solution, we can present it for Even to consider on a future revision. No?
 
As far as I'm concerned, this is more of an issue and pressing than testing instantx. The core drive of this coin is privacy and right now, change back under 1 and reused harms us. Make sure the core feature works first, then build on it. I realize instantx is done but we aren't just marketing a fast confirm coin... we are marketing a privacy-centric coin. Don't ever forget that. The 0.10 denomination cleans up a lot of this problem but it still leaves an issue with what amounts to being around 5c or less in value (sub 0.10). Do I dare say rid the random ds fee of 0.10 and use change 0.0999999999 and less as the "fee". It's still "cheap" for privacy.

The order should be (agree or disagree):

-Darksend
-Masternode obfuscation
-InstantX
 
Last edited by a moderator:
illodin said:
No you haven't, you spent inputs that were not anon. They were inputs that could be linked to earlier transactions. If you're referring to the example you posted earlier that is.
Click to expand...
No I wasn't referring to the example. I was talking about using the coin control in spending my real money.
 
paperThin said:
I agree with Crouton that a bandaid can be placed on this issue by
  • lowering the denominate a little
  • Setting aside "dead change" so that the user can have a clear understanding that it should be kept separate unless they choose to compromise anonymity.
However, even if this is not Even's most pressing item, it is worth a discussion to look for a solid long term solution. Definitely worth discussing! If we come up with something that sounds like a solid solution, we can present it for Even to consider on a future revision. No?
Click to expand...
Few corrections:
- "Evan" not "Even" ;)
- The whole point of lowering denoms is "No more change from anonymized funds. Ever. Or until we find better solution :)". So everything that do not fit is giving away - donations to Foundations, tx fee - doesn't matter. It should not arrive back to your wallet in current tx or in tx that is someway linked to current tx.

oblox said:
As far as I'm concerned, this is more of an issue and pressing than testing instantx. The core drive of this coin is privacy and right now, change back under 1 and reused harms us. Make sure the core feature works first, then build on it. I realize instantx is done but we aren't just marketing a fast confirm coin... we are marketing a privacy-centric coin. Don't ever forget that. The 0.10 denomination cleans up a lot of this problem but it still leaves an issue with what amounts to being around 5c or less in value (sub 0.10).
Click to expand...
I agree - strong privacy feature is a must here. But at the same time it looks like we want to find free solution while we can solve it at max price of $2.37 * 0.1 = 24c (at current price) per anonymous transaction. And thinking in that way... It makes me wonder - does it really even worth do discuss?... Is there any other solution that can give you comparable price-feature ratio? :confused:
 
UdjinM6 said:
I agree - strong privacy feature is a must here. But at the same time it looks like we want to find free solution while we can solve it at max price of $2.37 * 0.1 = 24c (at current price) per anonymous transaction. And thinking in that way... It makes me wonder - does it really even worth do discuss?... Is there any other solution that can give you comparable price-feature ratio? :confused:
Click to expand...

Exactly, and that isn't to say we can't re-evaluate denominations, perhaps to 0.025 or 0.01 when DRK is substantially higher so costs are always kept low. Sending a bunch of money with up to 0.10 worth of "fees" privately is hardly worth getting panties in a bunch over. This seems to make the most sense given the situation, risk:reward looks favorable and if we suck it up and change under 0.10 goes to the network, we never have to worry about change linking tx's again. Yes, the blockchain will bloat a bit but there are a few viable options for pruning and it's a far easier problem to solve IMHO than comprising privacy. The blockchain, especially dated blocks containing really old tx's, serves no purpose when the majority are going to unlinkable transactions of similar denominations. It's all fog.
 
Putting aside what development is more important, I agree with the general trend of the conversation.

Allow merchants to price at ~1 cent granularity, i.e. add 0.1 AND 0.01 denominations, and then trucate any excess and send it to the miners/MNs as a transaction fee automatically. As the price increases, then the denomination levels can be adjusted to maintain ~1 cent granularity.

This would add some bloat, but it would solve the problem and the excess dust stays in the system (rather than being auto-donated to someone's wallet) so if people want their dust back they can support the network by mining or setting up a MN.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top