Add Broadcast event in the Mixer

[AntoineRondelet]

See: Design described here: https://github.com/AntoineRondelet/blockchain-privacy

When Alice and Bob want to exchange the secret that is used to recompute a commitment (and used as input to generate a proof) one contract is used to break the link between both parties.
In fact, in order to protect her relationship with Bob, Alice wants to share the secret with him, but she does not want to be "seen" by the other peers in the network.

One way to do this is to exchange the secret off-chain.
Another way to do this, is to do it on-chain, and communicate through a "Broadcaster" contract. Alice encrypts the secret with Bob's public key, and sends a Tx containing the ciphertext to the Broadcaster contract. The broadcaster contract can't access the data (doesn't have the corresponding private key), and emits an even containing the ciphertext.
All peers of the network listen to this even, and try to decrypt the ciphertext. Only Bob can access the plaintext --> Alice and Bob shared a secret through encrypted broadcast on-chain, without leaking their relationship.

The above approach works with a separate contract "Broadcaster/TransactionRelay", but can also work if we add the ciphertext of the secret as another argument of the deposit function, and if we broadcast this ciphertext via an event at the end of the deposit function. This simplifies the design by deleting one contract, diminishes the number of transactions a party needs to trigger on the network.

[AntoineRondelet]

Current implementation for the Transaction Relay contract: https://github.com/AntoineRondelet/blockchain-privacy/blob/master/contracts/TransactionRelay.sol

[AntoineRondelet]

When the event is added to the Mixer contract, it can be useful to implement a python script in charge of listening of all the Broadcast events.

We can imagine something like, a script listening to broadcast events and trying to decrypt their content in a separate thread, and updating a store of "unspent/unrevealed secrets"

[barryWhiteHat]

Hmmm I need to think more about this. One problem is where does Alice get the gas to pay for the broadcast. This reveals that Alice made a payment but not to who. Bob knows that it was alice who made the payment which is fine.

I assumed that this would happen out of bound with whisper or something similar. What is your use case for doing it on chain?

[AntoineRondelet]

Yeah doing it off-chain is probably the best way to do, as we limit the amount of encrypted data we store on-chain... I thought about using the Broadcast event directly at the end of the "deposit" function, so that Alice does not need to do another call when she deposits, or in a separate contract (but then another call is required...)
There might probably be a use case for auditability measures to do it on-chain, although I'll need to put more thoughts into all of this.
I'll implement it when I have time and play with it to see how the flow goes ;p

[barryWhiteHat]

For me there seems no reason for user 1 to send a payment to user 2 and then not tell them that they did it. Its like just throwing away.

But you do have a point about auditiing. I would like to do that with a zksnark but i want to do everything with a zksnark :-P

[HarryR]

For me there seems no reason for user 1 to send a payment to user 2 and then not tell them that they did it. Its like just throwing away.

Say you tell user 2, then their computer dies, but it's OK because they have their keys backed up somewhere - then they just re-scan all of the broadcast events to discover which coins are theirs.

(e.g. current design of Monero, ZCash - view key, spend key, re-scanning)