Understanding the impact of privacy funding toward payment tx

[boolafish]

To be able to obfuscate the DEX funding, we need to make sure our payment transaction is in same format.

In this comment: https://github.com/omisego/research/issues/84#issuecomment-496345383 I propose to use output_type || hash(owner) instead of just owner_address in the field owner. Just wondering how much this would impact our existing systems?

Also, there might potentially be other better solutions for our existing tx (?)

cc. @paulperegud , @Pongch

[boolafish]

One thing I can think of with my proposal above is the tx itself would not be able to parse back the owner_address. For instance, if we are doing search via address in watcher or explorer this might cause issue? [edit: hmm, so would need to search via the hashed value with output_type instead.]

[paulperegud]

Does || denote concatenation? I use single | as alternative symbol.

Do you want to fit this into bytes32? Something like this?

bytes 0-1: output type, values in the range 0..65535
bytes 2-32: hash value, with preimage structure dependent on output type

There is a problem with structure above - it reveals that deposit is a deposit.

For instance, if we are doing search via address in watcher or explorer this might cause issue? [edit: hmm, so would need to search via the hashed value with output_type instead.]

Yeah, if we blind ownership, it would behave like that.

Also - I though about not using blinding in payments. We can introduce it via predicate if needed.

[boolafish]

@paulperegud, sorry was being lazy typing description.

In the previous GH issue description:

Solution - is as follows. We introduce additional possibility for the owner field of triple describing transaction output: {owner, token, address}. This field can contain:
  - 20 bytes of the address of the owner;
  - first 20 bytes of the hash of following string: output_type || owner (|| denotes concatenation).

The proposal here is to use the first 20 bytes of hash of the following string:

1. For payment tx: output_type || hash(owner)
2. For dex tx: output_type || hash(owner || exchange || nonce)

Or if you have any better proposal for payment output please let me know~

[paulperegud]

So one has to provide one preimage to reveal the output_type and other one to reveal the details. Do we have any flow where just revealing output_type is interesting? Or do you want to use it as a compact witness data in challenges?

@boolafish

[Pongch]

Hey @boolafish, sorry I got a lot of catching up to do here.

Is it a necessary requirement for payment tx to be different ? is it possible for payment tx to stay the same, how big of a value is the ability to obfuscate the DEX funding ?

[boolafish]

@Pongch, haha, actually I am using this issue to clear up my thought and to ask for ideas on what our payment tx should be like.

At the beginning of abstraction layer design, the output type is a key factor to be able to add new features. We use (outputType, consumeTxType) to get the predicate to verify spending condition. Thus it seems important to me to be able to get the outputType data out from output data.

However, we decide our first iteration of implementation would be without output predicate because we cannot really find a good predicate interface that is generalized enough yet.

Basically, that means we would need to predefine and hardcode all possible state transition from types to types in our exit game contract. (because we remove the feature to register new output predicate in the future) What I see it would probably be like:

1. challengeOutputUsedInPaymentTx()
2. challengeOutputUsedInDexSettlementTx()
3. challengeOutputUsedInUpgradeTx() <--- the upgrade tx itself is probably payment v2, which can then transit to, for instance, Dex v2. Quite likely the data structure of upgrade tx would need to be pre-defined (same as current payment tx) but how it can be spent and transfer to different kind of tx can be decided in the future.

(PS. in exit game, we only need to verify the spending condition in challenge)

hmmm, without a global output predicate registry system, and everything is limited within tx type, I think it is fine to keep the exact same data structure for payment output now, which is just use address as owner directly. User would need to choose different function to go through.

How do you think? @paulperegud cc. @pgebal @pik694

[boolafish]

[Note] If we are to do the predicate isolation with previous idea that move from set to set, it might be good reasoning for output type for payment because different sets would be using different output types.

Further discussion pending @paulperegud get better understanding of how the general code implementation would be look like.

So far, I think it is not a strong blocker at this moment as we can just use the old style. Might need to introduce breaking changes in the future though.

[boolafish]

Another issue I'd like to point out is that assuming we put the seed data of nonce encrypted in part of transaction, to keep the deposit tx being obfuscated via payment, payment need to be bloat with some random data too.

[EDIT: user would need one seed per venue. However, it could potentially just be stored in an DAPP instead of plasma tx]