search

input-output-hk / partner-chains-smart-contracts

Command Line Tool and Cardano Plutus Contracts for interacting with Partner Chains.
Apache License 2.0
9 stars 2 forks source link

FUEL claim verifying output address #5

Open szg251 opened 1 year ago

szg251 commented 1 year ago

Issue by: gege251 Original date: 2022-12-01 11:12:28 UTC Originally opened as: mlabs-haskell/trustless-sidechain/issues/290 Original assignees: Status on 2023-06-20: open

Description

In our current implementation we're verifying if the FUEL claim transaction was signed by the recipient, because of the way plutus-apps and bpi worked. However, in CTL, we might be able to actually verify the transaction output, if the tokens were minted and sent to the recipient address Context: https://github.com/mlabs-haskell/trustless-sidechain/pull/289#pullrequestreview-1200237929

Goals

Tests

Links

szg251 commented 1 year ago

Comment by: jaredponn Original date: 2022-12-02 05:47:27 UTC

Would we then still need to verify that the tokens are being sent to the above address? I made a new a ticket https://github.com/mlabs-haskell/trustless-sidechain/issues/290, where we can further discuss this.

Yes, I think we would need to verify that there is at least one transaction output for which tokens are being sent to the above address; but it no longer requires verifying if the recipient has signed the transaction.

The security argument of claiming the tokens would go something like this.

Claim. If a recipient has K FUEL and they are the recipient of s FUEL tokens from some MerkleTreeEntry, then recipient should have (at least) K + s tokens after the mint transaction.

And this should be true because of the following cases (it's rather immediate actually):

  1. There are no recipient outputs being spent in the transaction when MerkleTreeEntry is minted. Since mint forces the transaction to output to pay exactly (or at least) s tokens to recipient, and we know that none of the tokens in the transaction inputs belong to recipient (since we assumed this), this means that recipient must have K + s tokens after the transaction.

  2. Otherwise, there are recipient outputs being spent when the MerkleTreeEntry is minted. In which case, for this to succeed, recipient must have signed the transaction[^1], so recipient "intended" this to happen.

I don't think this would be more efficient (most likely just as efficient), but it does have the feature of letting someone else claim your tokens for you.

Of course, this would be much nicer to implement if we did change the mteRecipient field to be of type Address, so we wouldn't have to deserialize the bech32 address.

[^1]: See section 7.3 of the ledger specification http://cardano-universe.com/wp-content/uploads/2019/02/ledger-spec.pdf

szg251 commented 1 year ago

Comment by: jaredponn Original date: 2022-12-02 05:47:27 UTC

Would we then still need to verify that the tokens are being sent to the above address? I made a new a ticket https://github.com/mlabs-haskell/trustless-sidechain/issues/290, where we can further discuss this.

Yes, I think we would need to verify that there is at least one transaction output for which tokens are being sent to the above address; but it no longer requires verifying if the recipient has signed the transaction.

The security argument of claiming the tokens would go something like this.

Claim. If a recipient has K FUEL and they are the recipient of s FUEL tokens from some MerkleTreeEntry, then recipient should have (at least) K + s tokens after the mint transaction.

And this should be true because of the following cases (it's rather immediate actually):

  1. There are no recipient outputs being spent in the transaction when MerkleTreeEntry is minted. Since mint forces the transaction to output to pay exactly (or at least) s tokens to recipient, and we know that none of the tokens in the transaction inputs belong to recipient (since we assumed this), this means that recipient must have K + s tokens after the transaction.

  2. Otherwise, there are recipient outputs being spent when the MerkleTreeEntry is minted. In which case, for this to succeed, recipient must have signed the transaction[^1], so recipient "intended" this to happen.

I don't think this would be more efficient (most likely just as efficient), but it does have the feature of letting someone else claim your tokens for you.

Of course, this would be much nicer to implement if we did change the mteRecipient field to be of type Address, so we wouldn't have to deserialize the bech32 address.

[^1]: See section 7.3 of the ledger specification http://cardano-universe.com/wp-content/uploads/2019/02/ledger-spec.pdf