Skip to content

Instantly share code, notes, and snippets.

@phyro
Created May 9, 2020 19:23
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save phyro/5e46af67b696c331b58af9dfa3517740 to your computer and use it in GitHub Desktop.
Save phyro/5e46af67b696c331b58af9dfa3517740 to your computer and use it in GitHub Desktop.
obscuro_join.md

Bloat free decoy system

ObscuroDance

Obscuro dance is an action where someone buys an input->output pair for some fee. The peer from which the pair is bought can be anyone that has some UTXOs. The property we want to have is that the obscuro dance peer can't steal our fees and that we can't steal their input->output pair. If we want to pay them 1 grin per their input->output pair, we tell them to give us their input->output pair and that they can create another 1*H + r*G UTXO. We don't ask them to return a kernel, instead we just ask them to provide us with the private key P that is the difference of their inputs-outputs which includes the fee UTXO that they created. We can't steal their input->output pair because the private key includes a random r from their fee UTXO that we don't know. The dance peer also can't steal our fees because he does not have any information about the inputs.

ObscuroJoin

The ObscuroJoin flow then goes like this:

Alice wants to send 4 grins to Bob. She communicates with Bob that he can create an output with 4 grin and they sign the transaction which creates a simple regular MW transaction. Bob has not seen Alice's input or change output.

We now have a transaction that consists of:

inputs = [AliceInput]
outputs = [AliceChangeOutput, BobOutput]
kernel_point = K  # along with its sig
kernel_offset = O

Alice does not publish the transaction on the chain, instead she now communicates with a dance peer to obtain a new input->output pair from them together with their fee UTXO. Once she received their private key P, she adds P to the kernel offset O. She can do that with as many dance peers as she wants which contributes to transaction obfuscation. She adds another (or multiple) input to cover the fees for dance peers and adds that their part to the kernel offset.

We end up with a transaction where:

  1. Bob does not know from which output he received the money
  2. A dance peer only knows about his contributed input->output and the output which he created for his fee

This means that only Alice has information about the inputs and outputs, everyone else have no information about anything apart from their own inputs and outputs.

Alice can now broadcast her transaction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment