Alternative masternode blinding

[illodin]

INPUT = denominated input to the mixing transaction (address + value)
OUTPUT = output of the mixing transaction (address + value)
MN = masternode
Numbers used for count of peers and inputs/outputs are just examples.


1. SHARE INPUTS

• mixing peers(3) meet at the MN
• each peer has 10 inputs with coins and 10 outputs waiting for coins
• each peer sends its inputs(10) (address + pubkey + value) in clear text to the MN
• MN shuffles the list of inputs(30), and sends the shuffled list to each peer

2. ENCRYPT AND SHARE OUTPUTS

• each peer takes the public key of each input address in the list(30) and checks the public key matches the address (so MN has not changed it to perform man-in-the-middle)
• each peer now has a list of 30 inputs, and 30 public keys
• each peer encrypts each of its outputs(10) with random salts with a random public key (1 out of 30), one at a time
• each peer now has a list of 10 outputs, each encrypted with a different random public key
• each peer sends its encrypted outputs(10) to the MN
• MN shuffles the list of encrypted outputs(30), and sends the shuffled list to each peer

3. DECRYPT OUTPUTS

• each peer decrypts those encrypted outputs that it can, i.e. the outputs that were encrypted with its input addresses' public keys
• each peer sends the decrypted outputs(0-30) without salts to the MN

4. CREATE THE MIXING TRANSACTION

• MN now has 30 inputs and 30 outputs
• MN shuffles both lists and creates the mixing transaction
• MN sends the transaction to each peer
• each peer verifies that the inputs it knows(30) are all in the transaction
• each peer verifies that the outputs it knows(10-30) are all in the transaction
• if everything seems ok, each peer signs the transaction

5. ????


6. PROFIT



Even though there seems to be a lot of steps, every one of them is there for a reason (I think).

Some form of IP address hiding could also be added by using random masternode(s) as relays between peers and the mixer masternode, but let's ignore that for now.

Now I don't know how DoS prevention and collateral fit into all of this, or if this could even work. For example, can you encrypt and decrypt stuff with your addresses private and public keys? Is there any risk involved in giving out your public keys?

Thoughts? Could this work? If not, why? If it worked, can you see what it would accomplish?

 

[UdjinM6]

INPUT = denominated input to the mixing transaction (address + value)
....
3. DECRYPT OUTPUTS

• each peer decrypts those encrypted outputs that it can, i.e. the outputs that were encrypted with its input addresses' public keys
• each peer sends the decrypted outputs(0-30) to the MN

not 0-30 but 10 outputs this peer can decrypt only I guess... and then there is no point in whole encryption process because MN can clearly see who sent it

 

[illodin]

there is no point in whole encryption process because MN can clearly see who sent it

If you meant that when the peer decrypts an output, the MN can encrypt it again using each of the 30 public keys and see which public key produces the same encrypted result, then you're right, that's where I made an error. I edited the OP and added random salt to be encrypted with outputs.

 

[UdjinM6]

If you meant that when the peer decrypts an output, the MN can encrypt it again using each of the 30 public keys and see which public key produces the same encrypted result, then you're right, that's where I made an error. I edited the OP and added random salt to be encrypted with outputs.

Now with that changed I can't see why this can't work... Let me ping... eduffield flare Aswan Thoughts on this, guys?

EDIT: exact numbers (10,30) and equal input count for peers don't matter I guess, assuming that was for the ease of explanation
EDIT2: equal input count actually does matter