A question about verify_deprecation

#1

Hi. I have a question about verify_deprecation in multi sends case.

Scenario

single transfer -> multi sends transfer

Alice has range(0-100) and range(200-300) in block 1.
Alice sends range(0-100) and range(200-300) to Bob in block 2.

Of course, when Alice attempts exit range(0-100) in block 1, Bob can cancel Alice’s exit with block 2. And then Bob should show inclusions of both range(0-100) and range(200-300) because we wanna keep this multi-sends transaction atomically.

In pigi’s construction, verify_deprecation is chosen by exit state.

assert exit.update.predicateAddress.verifyDeprecation(stateID, exit.update, deprecationWitness)

So, where can we check all inclusions of deprecation state?

#2

Maybe self-solved. It’s same as swap scheme.

#3

Hello!!! :slight_smile:

It sounds like you may have figured it out, but to answer:

So, where can we check all inclusions of deprecation state?

The verifyDeprecation() is called on the original ownership state as you correctly pointed out. The actual conditions of deprecation are up to you to define (although we are working on full implementations of all the core predicates & contracts which we’ll share ASAP).

One example deprecation of simple ownership could be: any new StateUpdate signed by Alice & included in the correct position deprecates the old state.

However, in the case of the atomic swap we have a condition that we need 2 inclusion proofs! One way to handle this is make the atomic swap predicate act as an ownership predicate unless the 2nd half of the swap is included. So the swap predicate itself will enforce that either:

  1. Both halves of the swap are included so Bob is the new owner; or
  2. Only one half of the swap was included, the swap was unsuccessful, so Alice is still the owner.

This way even if one half of the swap is included, Alice is still OK allowing deprecation of her previous ownership predicate because to exit the swap predicate as Bob there needs to be an inclusion proof of both sides of the swap.

Does that make sense/answer your question?

PG: Fee Predicate
Architecture Design Idea of Atomic Swap Predicate
#4

Thank you very much!:grinning: Yes, this is I wanted to know! And I noticed @ben-chain has already taught me :sweat_smile: thanks!

Now I am thinking about the case withholding+invalid exit attempt attack for this multi-sends predicate. (Because I think swap predicate is also useful for multi-hop transfer and this construction can be applied other useful predicates)

This way even if one half of the swap is included, Alice is still OK allowing deprecation of her previous ownership predicate because to exit the swap predicate as Bob there needs to be an inclusion proof of both sides of the swap.

There is one point which concern me.

In the case

  • Alice and Bob has their coin in block 1. They will swap coins in block 2.
  • Bob and operator are malicious party
  • Both proof of swap states are withheld(but both are included correctly in block 2)
  • operator include invalid states(Bob is owner) in block 3

In this case, Alice attempts exit her coin in block 1 first. And all swap state will be revealed in exit-game as you described. But exit with invalid states in block 3 may succeed to withdraw in this period because invalid state in block 3 is just “OwnershipPredicate” which has 0 additional lockup time.

(although we are working on full implementations of all the core predicates & contracts which we’ll share ASAP

I am looking forward to full implementations!

#5

And this is my current understanding.