Apply suggestions from code review

PR github suggestions

Co-authored-by: Noon <[email protected]>

CHANGELOG.md

@@ -14,7 +14,7 @@ changes.
   with the community members building on Hydra. This feature means you can commit funds to a Head while it is running.
   TODO: Implement missing spec changes.
 
-- **BREAKING** hydra-node accepts multiple `hydra-scripts-tx-id` as the outcome of changes in the Hydra scripts publishing.
+- **BREAKING** hydra-node accepts multiple `hydra-scripts-tx-id` as a comma-seperated list, as the outcome of changes in the Hydra scripts publishing.
 
 - Tested with `cardano-node 10.1.2` and `cardano-cli 10.1.1.0`.
 

docs/docs/dev/incremental-commits-and-decommits.md

@@ -32,7 +32,7 @@ curl -X POST <IP>:<PORT>/commit --data @commit.json
 
 :::info
 
-Note that commit transaction, which is sent to the hydra-node API, only needs
+Note that the commit transaction, which is sent to the hydra-node API, only needs
 to specify the transaction inputs present in L1 that we want to make available
 on L2. It will ignore any specified outputs and instead the owner of
 incremented `UTxO` on L2 is the same one that owned the funds on L1.
@@ -49,7 +49,7 @@ It goes together with a `UTxO` used to resolve the transaction inputs. It's
 purpose is to prove that one can spend specified transaction inputs.
 
 Successfull API response includes a _deposit_ transaction that needs to be
-signed and submitted by the user in order to kick of the deposit process.
+signed and submitted by the user in order to kick-off the deposit process.
 
 This process just locks the specified `UTxO` at a deposit script address which
 will then, later on, after confirmed snapshot, be unlocked by the _increment_
@@ -67,7 +67,7 @@ Once a hydra-node observes a deposit transaction it will record the deposit as
 pending into the local state. There can be many pending deposits but the new
 Snapshot will include them one by one.
 
-When this new Snapshot is ackgnowledged by all parties _increment_ transaction
+When this new Snapshot is acknowledged by all parties _increment_ transaction
 will be posted by the leader.
 
 :::info

hydra-cluster/src/Hydra/Cluster/Faucet.hs

@@ -149,7 +149,6 @@ createOutputAtAddress ::
 createOutputAtAddress node@RunningNode{networkId, nodeSocket} atAddress datum val = do
   (faucetVk, faucetSk) <- keysFor Faucet
   utxo <- findFaucetUTxO node 0
-  -- pparams <- queryProtocolParameters networkId nodeSocket QueryTip
   let collateralTxIns = mempty
   let output = TxOut atAddress val datum ReferenceScriptNone
   -- let output =

hydra-tx/src/Hydra/Tx/Recover.hs

@@ -16,7 +16,6 @@ import Hydra.Ledger.Cardano.Builder (
 import Hydra.Plutus (depositValidatorScript)
 import Hydra.Tx (HeadId, mkHeadId)
 import Hydra.Tx.Utils (mkHydraHeadV1TxName)
-import PlutusLedgerApi.V1 (CurrencySymbol, POSIXTime)
 
 -- | Builds a recover transaction to recover locked funds from the v_deposit script.
 recoverTx ::
@@ -64,7 +63,7 @@ observeRecoverTx networkId utxo tx = do
   let inputUTxO = resolveInputsUTxO utxo tx
   (TxIn depositTxId _, depositOut) <- findTxOutByScript @PlutusScriptV3 inputUTxO depositScript
   dat <- txOutScriptData $ toTxContext depositOut
-  (headCurrencySymbol, _, onChainDeposits) <- fromScriptData dat :: Maybe (CurrencySymbol, POSIXTime, [Commit.Commit])
+  (headCurrencySymbol, _, onChainDeposits) <- fromScriptData dat :: Maybe Deposit.DepositDatum
   deposits <- do
     depositedUTxO <- traverse (Commit.deserializeCommit (networkIdToNetwork networkId)) onChainDeposits
     pure $ UTxO.fromPairs depositedUTxO