Reject unsupported transactions

[ch1bo]

What & Why

Although the ledger implementation used in the hydra-node is the same as in cardano-node, not all ledger rules make sense in a Hydra Head. For example, stake pool registrations and submitting delegation certificates have no meaning on Layer 2.

Furthermore, there are still some temporary gaps (#196) which need to be closed and corner-cases of PlutusV1 shortcomings (byron addresses). To provide a good user experience, these transactions shall be filtered at the API, but also need to be checked for when receiving them from another hydra-node.

Requirements

• Commit Hydra protocol transactions do not use byron addresses.
• Transactions received via API are checked and an explanatory response is sent
• Transactions received via Network are checked and errors are only logged
• Transactions to be filtered (not supported):
  • using tx validity bounds ("timed transactions", for now)
  • using byron addresses
  • anything kind of certificates
  • withdrawals
  • protocol updates
  • minting/burning (at least for now)

Tasks

• Reject on-chain commit transactions when trying to commit a UTxO entry locked by a Byron address. #320
• Define a newtype Restricted Tx with a safe interface for constructing transactions that are valid with respect to Hydra heads limitations (see above).
• Replace use of raw Tx in the ClientInput API with their restricted type.
• Replace use of raw Tx on the network side, to prevent other peers from sending wrong transactions to us

[abailly-iohk]

Rather than adding complexity in the off-chain ledger, we could add those checks where they belong, in the on-chain ledger interface, and prevent CloseTx transaction from being posted depending on various conditions. This would not prevent someone to craft such a transaction outside of the Hydra node though.

[ch1bo]

We consider pausing this effort, after solving the first requirement, and revisit this when we have more feedback for or against this feature.

[ch1bo]

We discussed this again and realize that the most important bit of this would be

Double-check that any close transaction snapshot we sign can be fanned out, reject them otherwise.

We aim to create a follow-up/alternative feature which mostly focuses on that and delays snapshot signing instead of rejecting transactions. This would allow minting "outside of snapshots", i.e. not having snapshots covering the txs with minted tokens, unless they are burned.

[ch1bo]

Created #370 to capture more directly the security concern of unclosable Heads, whereas this item here aims at improving the UX on unsupported transactions.

[ch1bo]

Closed in favor of #370