Quote from: camosoul on July 08, 2014, 04:14:57 AM

Quote from: eduffield on July 07, 2014, 11:39:02 PM

Please tell me someone will be ready to put this on the OP and draw attention to the fact that DS has been drastically changed/improved?

Shame to wait for days for an OP update on something this big...

How does it deal with decimal point leftovers? Those could act like flags on change addresses... When do you send exact even numbers anywhere? Shouldn't these be duff-level denominations? Image just dumbed down?

That sub-1 change still has all sorts of problems from my perspective (note: when sending a "rounded" tx, the above method seems pretty nearly flawless; the only weakness I can think of at this time is if there's say 3 transactions happening, and one of the wallets doing the sending has (and is trying to send) less than either of the other two. It wouldn't work in this case, as one could still simply follow inputs/outputs.)

A way to somewhat alleviate the above scenario would be to have a "Prepare wallet for Darksend+" button, which would complete step one (with masternode 1), leaving a bunch of denominated change around to send in later transactions. Then you would have different transactions involved in an actual Darksend+ transaction versus who shared in the change denomination session.

But back to the sub-1 change issue. Let's say we need to send 17.54321 DRK from A to B (we can ignore other senders/receivers):

A sends 20 DRK to MN1; he get's change back as follows:
C gets 10 DRK
D gets 5 DRK
E gets 1 DRK
F gets 1 DRK
G gets 1 DRK
H gets 1 DRK
I gets 0.54321 DRK
J gets 0.45679 DRK

Now the transaction can proceed as normal, going to MN2 as expected (addresses C, D, E, F, and I get sent). B receives the requested 17.54321 DRK.

The problem is address J is now tainted and could potentially link some things together if used for future transactions with F, G, and H (if used with all 3 simultaneously, it would 100% link the original A to B tx). Additionally, it has the further weakness of not being very useful for future Darksend+'s, as it won't denominate well.

The potential "fix" that's on my mind (maybe just a workaround) is to store up these "tainted", mostly useless addresses until you have them totaling more than 1 (or 5, or whatever), at which point they could be sent to a special "redenominating" pool (and maybe you don't even need a pool, I haven't taken the time to think through all the implications of just doing it like a normal Darksend+) for recycling back to standard sized change addresses. You would still end up with one sub-1 address every time, but that's not too big of deal in my view.

Any thoughts?