user387: I'm having a newtype VerificationKey = HydraVerificationKey (VerKeyDSIGN Ed25519DSIGN) and I would love to be able to use that type directly in our plutus scripts. While I can implement PlutusTx.ToData et al for it and satisfy ghc, I get runtime errors like
Benchmark tx-cost: RUNNING...
tx-cost: Error: Unsupported feature: Kind: GHC.Types.Nat
Context: Compiling definition of: Hydra.Contract.HeadTokens.validateTokensMinting
Context: Compiling definition of: Hydra.Contract.HeadTokens.validate
Context: Compiling expr at "hydra-plutus-0.5.0-inplace:Hydra.Contract.HeadTokens:(120,8)-(120,101)"

Likely because the VerKeyDSIGN (from Cardano.Crypto.Class) is implemented using some reflection on key size using Nat, as it's defined:
newtype VerKeyDSIGN Ed25519DSIGN = VerKeyEd25519DSIGN (PinnedSizedBytes (SizeVerKeyDSIGN Ed25519DSIGN))

newtype PinnedSizedBytes (n :: Nat) = PSB ByteArray

But we would not want to be using HydraVerificationKey nor the underlying VerKeyEd25519DSIGN data constructors, but only functions
dealing with the newtype VerificationKey . Is this even possible?
Right now we are converting our off-chain keys to another, simpler type newtype Party = UnsafeParty {vkey :: BuiltinByteString}, but thought we could avoid that conversion.

user6948: I think you must be using the datatype in some way if you're doing anything with this type.
However, perhaps you just don't care about the Nat index. It would be nice to be able to ignore this, but how would you communicate this to the compiler? You really want to say "don't use this definition of the type, use this other definition of the type that doesn't have this parameter". But the simplest way to do that is just to: use the other definition of the type, which is what you're doing.
Possibly we could ignore phantom type parameters in general, but we'd have to be very careful that this didn't result in ill-typed Plutus IR. Generally throwing away bits of type information and hoping it will be okay is risky!

387: <p>I'm having a <code>newtype VerificationKey = HydraVerificationKey (VerKeyDSIGN Ed25519DSIGN)</code> and I would love to be able to use that type directly in our plutus scripts. While I can implement <code>PlutusTx.ToData</code> et al for it and satisfy ghc, I get runtime errors like</p>
<pre><code>Benchmark tx-cost: RUNNING...
tx-cost: Error: Unsupported feature: Kind: GHC.Types.Nat
Context: Compiling definition of: Hydra.Contract.HeadTokens.validateTokensMinting
Context: Compiling definition of: Hydra.Contract.HeadTokens.validate
Context: Compiling expr at &quot;hydra-plutus-0.5.0-inplace:Hydra.Contract.HeadTokens:(120,8)-(120,101)&quot;
</code></pre>
<p>Likely because the <code>VerKeyDSIGN</code> (from <code>Cardano.Crypto.Class</code>) is implemented using some reflection on key size using Nat, as it's defined:</p>
<pre><code>newtype VerKeyDSIGN Ed25519DSIGN = VerKeyEd25519DSIGN (PinnedSizedBytes (SizeVerKeyDSIGN Ed25519DSIGN))

newtype PinnedSizedBytes (n :: Nat) = PSB ByteArray
</code></pre>
<p>But we would not want to be using <code>HydraVerificationKey</code> nor the underlying <code>VerKeyEd25519DSIGN</code> data constructors, but only functions
dealing with the <code>newtype VerificationKey</code> . Is this even possible?</p>
<p>Right now we are converting our off-chain keys to another, simpler type <code>newtype Party = UnsafeParty {vkey :: BuiltinByteString}</code>, but thought we could avoid that conversion.</p>
 6948: <p>I think you must be using the datatype in some way if you're doing <em>anything</em> with this type.</p>
<p>However, perhaps you just don't care about the <code>Nat</code> index. It would be nice to be able to ignore this, but how would you communicate this to the compiler? You really want to say &quot;don't use this definition of the type, use this <em>other</em> definition of the type that doesn't have this parameter&quot;. But the simplest way to do that is just to: use the other definition of the type, which is what you're doing.</p>
<p>Possibly we could ignore phantom type parameters in general, but we'd have to be very careful that this didn't result in ill-typed Plutus IR. Generally throwing away bits of type information and hoping it will be okay is risky!</p>
