Using curve P384 for encryption causes the error "ecies: shared key params
are too big". Also, readme.md says curve P384 should use AES192 not AES256.
Co-authored-by: Marius van der Wijden <m.vanderwijden@live.de>
* core: implement eip-4399 random opcode
* core: make vmconfig threadsafe
* core: miner: pass vmConfig by value not reference
* all: enable 4399 by Rules
* core: remove diff (f)
* tests: set proper difficulty (f)
* smaller diff (f)
* eth/catalyst: nit
* core: make RANDOM a pointer which is only set post-merge
* cmd/evm/internal/t8ntool: fix t8n tracing of 4399
* tests: set difficulty
* cmd/evm/internal/t8ntool: check that baserules are london before applying the merge chainrules
The loop variable changes before the defer executes, so we need to
pass it to the function to make sure the closure has the correct
version of the loop variable.
It turns out we were only notifying plugins of freezer commits and
cleaning up our record when the block being processed was greater
than MAX_UINT64.
So, uh, never.
While looking for the source of a memory leak, I decided to optimize
the metatracer to avoid encoding values when there weren't any tracers
configured to received the encoded values.
I also avoided putting the EVM into debug mode when there weren't any
tracers configured.
None of these fixed the memory leak, but they still seem like good
practices. Memory leak fix is in the next commit.
SyncProgress was modified in PR #23576 to add the fields reported for
snap sync. The PR also changed ethclient to use the SyncProgress struct
directly instead of wrapping it for hex-decoding. This broke the
SyncProgress method.
Fix it by putting back the custom wrapper. While here, also put back the
fast sync related fields because SyncProgress is stable API and thus
removing fields is not allowed.
Fixes#24180Fixes#24176
Fixes#24167
New behaviour is that the endpoint returns results only for available
blocks without returning an error when it doesn't find a block. Note we
skip any block after a non-existent block.
This adds a header fetch for every block in range (even if header
is not needed). Alternatively, we could do the check in every field's
resolver method to avoid this overhead.
