Search results

My client has been stuck for 2 days. (At first it was mixing very well.) I had tried zapping the wallet several times over those 2 days. Today, it picked up and started mixing again. Yay! Meanwhile, I loaded the Mac Client for the first time ever. Looks good, thanks devs! The question I...

Lone Crouton, Have you gotten past this yet? I am zapping wallet now. After that, I sent the whole wallet's value (all inputs selected) to a new address (in the same wallet). After confirming the required times, I will restart mixing.

Thank you so much, Development Team. I was unable to follow the test cycle, but I download the new client today. WOW! You have brought it so far. Thank YOU!

185 DRK, 99999 rounds (LP) liquidityprovider set to "1" (That means "much" mixing, right?) The comment says "Darksend is idle". With the old client it used to change the phrase like... "attempting darksend mixing" periodically. This one has not changed from "Darksend is idle". I have 8...

I am already mixed at round 9. The new client does not allow a higher setting. (So I can't mix with the regular client.) I will try using LP now.

Moli, I can mix if you want. I am running the regular client.

This. Most concisely stated. Temporary, but immediate solution. I support this idea!

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

Moli, Not sure the point you are driving at... but I can see that your 9.0000015 is related to the address: mmfb6hxTdLT3gQGAEDr2g6Qug8ew2MwKoJ Which has a balance of 907 tDRK. Everything that mmfb6hxTdLT3gQGAEDr2g6Qug8ew2MwKoJ has done, which is a lot of transactions are tied to the 9.000015...

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

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

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.

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

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.

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

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

Thanks Evan!

Yes, you are right. My thought was that if several people are receiving small change back to new addresses then it would be difficult to tell which change corresponded with with each user. By breaking the amounts in pieces, it adds complexity, but probably not enough. Simple example: If...

Aswan, [Edit: This is not going to work as presented.... but maybe it will spark an idea with someone else that can improve it.] Coming back with a second idea... (not "Jar Mix") First I need to be clear that I understand this correctly: There is some exposure from a single malicious...

I have a couple ideas, but I need to put them together as concisely as I can so that Aswan can destroy them better :wink: ... still thinking on it!