Dead Change - an anonymity issue

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!
 
paperThin said:
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!
Click to expand...

Is anyone still using Aswan? I haven't used that in months.

Wow mixed up a username with software.

moli I believe going under 1 drk would cause tremendous bloat.
 
Last edited by a moderator:
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 masternode (as the system exists today) at the point of a private purchase if that specific masternode happens to be the one receiving the transaction. Is that right? What is the exposure? Is it just the IP address of the person making the transaction request? Is there any other identifying characteristics? (Of course I realize the blockchain in/out address, but the whole world is able to see that.)​
Assuming above is correct, then the malicious masternode (using Jar Mix) is able to link 2 completely separate transactions because the user is asking to consolidate them to a single address. This lets a malicious masternode "know and remember" both that the two (output) addresses are linked and where the funds were directed to (input). Other masternodes on the network may see the result to the mix, but only that one MN knows exactly how things were shuffled.

OK, assuming I have no inaccuracies above, I am presenting a new idea here (new for me):
Unlike the "Jar Mix" idea, this one requires quite a bit of change in how the Masternodes operate. (That's a negative to this idea.)
Also, let's assume that DSD is "fixed" to use whole numbers. :)
  • The key here is: All Masternodes only return whole number change on the first step. For example a purchase of 7.25 is made with a 10 DRK address. The buyer receives 2 DRK back in that same transaction while the seller receives the whole 7.25. (0.75 DRK stays with the Masternode for now.)
  • (The 2.0 DRK change is perfectly safe for remixing by the user.)
  • The 0.75 held by the Masternode goes into one(1) of five(5) addresses held by the Masternode. These addresses should rotate new ones in and abandon old ones.
  • The Masternode waits 1, 2, or 3 blocks and then sends 0.75 from any of the 5 addresses to a user address (separate and unused address) through another masternode.
Of course this Masternode is aware of the complete transaction (Outputs and Inputs), but it is only a single transaction (not 2 linked together) and the rest of the network is not able to detect this as "returned change".
  • I see a weakness here that exposes "strange change" (ie 0.12345 DRK). This would be easy to spot later in the blockchain.
    • Could the MN break the change into pieces and send it from 2 separate addresses?
  • A masternode would be able to shutdown and "keep the change", but it would always be less than 1 DRK that the user would lose. The user would get the bulk of the change (ie whole numbers) in the same transaction, so losses would not be too great. Would it be worthwhile for malicious nodes to startup, steal change, shut down, restart with new ID... etc?
 
paperThin said:
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 masternode (as the system exists today) at the point of a private purchase if that specific masternode happens to be the one receiving the transaction. Is that right? What is the exposure? Is it just the IP address of the person making the transaction request? Is there any other identifying characteristics? (Of course I realize the blockchain in/out address, but the whole world is able to see that.)​
Assuming above is correct, then the malicious masternode (using Jar Mix) is able to link 2 completely separate transactions because the user is asking to consolidate them to a single address. This lets a malicious masternode "know and remember" both that the two (output) addresses are linked and where the funds were directed to (input). Other masternodes on the network may see the result to the mix, but only that one MN knows exactly how things were shuffled.

OK, assuming I have no inaccuracies above, I am presenting a new idea here (new for me):
Unlike the "Jar Mix" idea, this one requires quite a bit of change in how the Masternodes operate. (That's a negative to this idea.)
Also, let's assume that DSD is "fixed" to use whole numbers. :)
  • The key here is: All Masternodes only return whole number change on the first step. For example a purchase of 7.25 is made with a 10 DRK address. The buyer receives 2 DRK back in that same transaction while the seller receives the whole 7.25. (0.75 DRK stays with the Masternode for now.)
  • (The 2.0 DRK change is perfectly safe for remixing by the user.)
  • The 0.75 held by the Masternode goes into one(1) of five(5) addresses held by the Masternode. These addresses should rotate new ones in and abandon old ones.
  • The Masternode waits 1, 2, or 3 blocks and then sends 0.75 from any of the 5 addresses to a user address (separate and unused address) through another masternode.
Of course this Masternode is aware of the complete transaction (Outputs and Inputs), but it is only a single transaction (not 2 linked together) and the rest of the network is not able to detect this as "returned change".
  • I see a weakness here that exposes "strange change" (ie 0.12345 DRK). This would be easy to spot later in the blockchain.
    • Could the MN break the change into pieces and send it from 2 separate addresses?
  • A masternode would be able to shutdown and "keep the change", but it would always be less than 1 DRK that the user would lose. The user would get the bulk of the change (ie whole numbers) in the same transaction, so losses would not be too great. Would it be worthwhile for malicious nodes to startup, steal change, shut down, restart with new ID... etc?
Click to expand...

I don't believe this is a worry with the system as is. To do so, you are essentially removing your entry into the masternode list until the new vin is confirmed by a number of blocks equal to approx. the number of outstanding masternodes on the network. By doing so, you are pocketing "change" at the expense of being included in payouts of the block reward until reconfirmed and added back to the list for round robin style selection.

The change going to a masternode that continues to flow onward to other masternodes randomly is an interesting take. But if it isn't combined at some point, isn't it just a matter of a bread trail to be followed before it returns to an address owned by the same person that sent the change?
 
oblox said:
I don't believe this is a worry with the system as is. To do so, you are essentially removing your entry into the masternode list until the new vin is confirmed by a number of blocks equal to approx. the number of outstanding masternodes on the network. By doing so, you are pocketing "change" at the expense of being included in payouts of the block reward until reconfirmed and added back to the list for round robin style selection.

The change going to a masternode that continues to flow onward to other masternodes randomly is an interesting take. But if it isn't combined at some point, isn't it just a matter of a bread trail to be followed before it returns to an address owned by the same person that sent the change?
Click to expand...

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 change due is 0.40 (user 1) and 0.60 (user 2), then 5 payments of 0.20 to 5 separate addresses (2 addresses of user 1 and 3 addresses of user 2).
​
But I agree, your point is right... not easy to follow, but does leave a trail of bread crumbs. Still working on it... I have a different idea...
 
paperThin said:
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 change due is 0.40 (user 1) and 0.60 (user 2), then 5 payments of 0.20 to 5 separate addresses (2 addresses of user 1 and 3 addresses of user 2).
​
But I agree, your point is right... not easy to follow, but does leave a trail of bread crumbs. Still working on it... I have a different idea...
Click to expand...
In your example about evening out change, I see that, but aren't you essentially creating another denomination. If you are going to send micro amounts (less then 1 DRK), aren't you better off introducing a 0.10 denomination overall into the darksend process?

What if change is accumulated on the masternodes, that continues to flow masternode to masternode after getting combined into new addresses. The masternodes as a consensus lock the last address from the ability to withdrawal and the client keeps track of how much change they are suppose to get back until it gets above a threshold to allow denominations to come back. It doesn't solve an issue if the masternode containing all the coins goes offline even though the masternode consensus should prevent those funds from being able to be sent anywhere other than where the consensus tells them to go. Probably oodles of flaws in there.

The other idea is using the reference nodes but then again, you are introducing a centralized aspect, even if change is small.
 
You must log in or register to reply here.
Back
Top