Skip to content
This repository has been archived by the owner on Jun 6, 2024. It is now read-only.

zkvm: stellar-zkvm import/export protocol draft #297

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

oleganza
Copy link
Contributor

@oleganza oleganza commented Apr 26, 2019

You can view the rendered doc in this PR here:

📄 Import/export specification

@oleganza oleganza force-pushed the oleg/peg-spec branch 3 times, most recently from ead7f7a to 8647c40 Compare April 26, 2019 20:36
@oleganza oleganza changed the title zkvm: stellar-zkvm pegging protocol draft zkvm: stellar-zkvm import/export protocol draft Apr 30, 2019
@oleganza oleganza marked this pull request as ready for review April 30, 2019 23:37
@oleganza
Copy link
Contributor Author

Update: @jonjove has pointed out a possible attack on user's peg-out transaction, destroying their funds, and offered a possible solution.

Attack

  1. User prepares a temp Stellar transaction that acts as uniqueness anchor.
  2. User forms a withdrawal Stellar transaction that spends and closes that temp account, but also pays from the custodian's account the $V being exported.
  3. User retires mapped $V on the sidechain, annotating it with the temp account's ID and sequence number.
  4. User asks the custodian to co-sign the withdrawal transaction.
  5. Custodian checks the proof of publication of the retirement tx, co-signs the withdrawal.
  6. Meanwhile, an attacker sends $X to user's account, to make it sufficiently close to the trustline limit. Of course, if required $X is ≥ $V, then attacker does not actually deprive the user of $V. The attack relevant if the user's remaining trustline limit is less than 2x$V.
  7. If the user does not bump that limit before publishing the withdrawal tx, the temp account's sequence number will be consumed, tx included in the ledger, but transfers will not happen. Since the retired funds are tied to a specific seqnum (for anti-replay reasons), user cannot try again to withdraw those funds.

Proposed solution

  1. The spec should include creation of an offer that pays a dummy asset for $V amount. This "reserves" a buffer of $V for the trustline, so the attacker sending money to the account cannot squeeze it more than to that much.
  2. The withdrawal tx has one more operation, preceding the payout of $V from custodian: destroying that offer, which clears room for receiving $V, even if trustline is maxed out.

I think there might be a simpler option: the user may pay to their temporary account, which is originally set up with max trustline, that's impossible to max out without paying the user more than $V.

@oleganza
Copy link
Contributor Author

Another point raised by @jonjove is that assets should not have AUTH_REQUIRED and also be AUTH_IMMUTABLE so that export process cannot be interrupted mid-way.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant