Christian Lewe

Maybe "The parent of a hidden node is not an assertion." Assertions are defined to be case nodes with one left or right hidden child.

We should experiment to see if [the way we use unification arrows](https://github.com/BlockstreamResearch/rust-simplicity/blob/acbd3ad8de8f3dfe1cda3683ba5d88dadedddeed/src/inference.rs#L218-L225) results in weird error messages.

Type variables get names of the form `disconnect_b_10` where `disconnect` is the combinator type, `b` is the type variable of disconnect (from the tech report) and `10` is an index....

I'm a little bit scared that a random program caused so much trouble. Is there a way to search for these hyperexpensive programs? > 1. We can presume/require that nodes...

We should add `--` to the [list of reserved symbols that are not NAMEs](https://github.com/BlockstreamResearch/rust-simplicity/blob/04a30aaac63cd9eca234039ee4bb6ba76c6a883a/src/human_encoding/README.md?plain=1#L38-L46). Edit: Actually any string that matches `.*\-\-.*` should not be a NAME.

We also need to update the cost of disconnect: https://github.com/BlockstreamResearch/simplicity/pull/168

Needs update of the overhead value: https://github.com/BlockstreamResearch/simplicity/pull/174

`JetNode` and `JetName` have been replaced with `Jet` in #44 . `TypeName` still exists, but it is hard (impossible?) to represent a finalised type with heap allocations in compile-time code....

Ideally policy includes `absolute::Locktime` and `relative::Locktime`. Is the latter implemented for rust-elements? rust-bitcoin wants you to generate `relative::Locktime` through `Sequence`. Maybe we should write our own enums.

Should we use `bitcoin`'s structures or `elements`'s? Keeping everything policy-related consistent with Elements might have benefits down the line.