Previously we were dropping events that used old
wires that lacked a rift in them. This seems a
bad behavior because we don't want to destroy a
flow that has not been processed by both ends.
Note: pending a fix to test-old-ames-wire
Threads should eventually take and produce $cage instead of $vase. Since
%khan is likely to be used by third parties, we write to the eventual
intended API. We ignore the mark on the input $cage (it is safe to
always specify %noun), and we always use %noun as the output mark.
%fyrd now makes more sense. It was previously discarding the type of the
output %arow and re-encoding the raw noun as a vase of the output mark;
it is now performing mark conversion from the mark of the output $cage
to the originally requested output mark.
Also strips out `$` from khan top-level comment.
There are arguments for keeping $crag in lull, and on the other side for
moving $cast to arvo. This seemed like the most reasonable approach.
%fyrd is now implemented in terms of %fard, and likewise %avow in terms
of %arow. State is tracked via wire rather than in a global map.
Unit tests adjusted to match.
+sign:schnorr crashes on `=(0 sk)`, so the bounds checking code is not
exercised for sk=0. It also crashes on `(gte sk n.domain.c)`, which is
redundant with the size check on sk, so we remove that.
;;(vase ...) does a nest-check of the type of the kernel. This is
undesirable, so we instead run everything through +slum and cast the
result to +tang.
Adds a new transaction type and signing method for eip-1559-style
transactions.
Includes a $typed-transactions type which can support any number of
eip-2718-style typed transactions.
Previously, this would measure as <20 bytes for addresses with leading
zeroes. This resulted in transactions with unexpected behavior.
For example, sending ETH to the zero address would create a contract
instead.
Here we switch to using +encode:rlp directly and indicate a width of
20 bytes for the "to" field.
Null bytes in lists were getting eaten during concatenation. To avoid
this, we track encoded item widths (which are always 1 or higher) and
+can them all together.
This likely did not affect any of the other Ethereum code, considering
it nearly always measures atoms, and the null byte would be seen as
no bytes in that case.
