This is one further step towards removing account management from
`geth`. This PR deprecates the flag `unlock`, and makes the flag moot:
unlock via geth is no longer possible.
This PR is a first step towards removing account management from geth,
and contains a lot of the user-facing changes.
With this PR, the `personal` namespace disappears. **Note**: `personal`
namespace has been deprecated for quite some time (since
https://github.com/ethereum/go-ethereum/pull/26390 1 year and 8 months
ago), and users who have wanted to use it has been forced to used the
flag `--rpc.enabledeprecatedpersonal`. So I think it's fairly
non-controversial to drop it at this point.
Specifically, this means:
- Account/wallet listing
-`personal.getListAccounts`
-`personal.listAccounts`
-`personal.getListWallets`
-`personal.listWallets`
- Lock/unlock
-`personal.lockAccount`
-`personal.openWallet`
-`personal.unlockAccount`
- Sign ops
-`personal.sign`
-`personal.sendTransaction`
-`personal.signTransaction`
- Imports / inits
-`personal.deriveAccount`
-`personal.importRawKey`
-`personal.initializeWallet`
-`personal.newAccount`
-`personal.unpair`
- Other:
-`personal.ecRecover`
The underlying keystores and account managent code is still in place,
which means that `geth --dev` still works as expected, so that e.g. the
example below still works:
```
> eth.sendTransaction({data:"0x6060", value: 1, from:eth.accounts[0]})
```
Also, `ethkey` and `clef` are untouched.
With the removal of `personal`, as far as I know we have no more API
methods which contain credentials, and if we want to implement
logging-capabilities of RPC ingress payload, it would be possible after
this.
---------
Co-authored-by: Felix Lange <fjl@twurst.com>
When attempting to hash a typed data struct that includes a type
reference with a fixed-size array, the validation process fails.
According to EIP-712, arrays can be either fixed-size or dynamic,
denoted by `Type[n]` or `Type[]` respectively, although it appears this
currently isn't supported.
This change modifies the validation logic to accommodate types
containing fixed-size arrays.
* .golangci.yml: enable check for consistent receiver name
* beacon/light/sync: fix receiver name
* core/txpool/blobpool: fix receiver name
* core/types: fix receiver name
* internal/ethapi: use consistent receiver name 'api' for handler object
* signer/core/apitypes: fix receiver name
* signer/core: use consistent receiver name 'api' for handler object
* log: fix receiver name
This PR replaces Geth's logger package (a fork of [log15](https://github.com/inconshreveable/log15)) with an implementation using slog, a logging library included as part of the Go standard library as of Go1.21.
Main changes are as follows:
* removes any log handlers that were unused in the Geth codebase.
* Json, logfmt, and terminal formatters are now slog handlers.
* Verbosity level constants are changed to match slog constant values. Internal translation is done to make this opaque to the user and backwards compatible with existing `--verbosity` and `--vmodule` options.
* `--log.backtraceat` and `--log.debug` are removed.
The external-facing API is largely the same as the existing Geth logger. Logger method signatures remain unchanged.
A small semantic difference is that a `Handler` can only be set once per `Logger` and not changed dynamically. This just means that a new logger must be instantiated every time the handler of the root logger is changed.
----
For users of the `go-ethereum/log` module. If you were using this module for your own project, you will need to change the initialization. If you previously did
```golang
log.Root().SetHandler(log.LvlFilterHandler(log.LvlInfo, log.StreamHandler(os.Stderr, log.TerminalFormat(true))))
```
You now instead need to do
```golang
log.SetDefault(log.NewLogger(log.NewTerminalHandlerWithLevel(os.Stderr, log.LevelInfo, true)))
```
See more about reasoning here: https://github.com/ethereum/go-ethereum/issues/28558#issuecomment-1820606613
Accept all primitive types in Solidity for EIP-712 from intN, uintN, intN[], uintN[] for N as 0 to 256 in multiples of 8
---------
Co-authored-by: Martin Holst Swende <martin@swende.se>
This PR adds a check that the safetxhash that we sign corresponds to the one that is expected by the input. If it differs, it tries again with the configured chainid.
This PR should makes it easier to sign EIP-712 typed data via the accounts.Wallet API, by using the mimetype for typed data.
Co-authored-by: nasdf <keenan.nemetz@gmail.com>
