FUEL claim verifying output address

[szg251]

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

• Discuss pros/cons

Tests

Links

• meta-task input-output-hk/trustless-sidechain#181

[szg251]

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¹, 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.

Footnotes

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

[szg251]

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¹, 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.

Footnotes

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