The pre-computed table for speeding up ScalarBaseMultNonConst is
several hundred kilobytes in the binary and even more when unpacked
into working memory. Special-case ScalarBaseMultNonConst to fall back to
ScalarMultNonConst when the 'tinygo' tag is specified, which is true
when building a Go program with TinyGo.
This updates the docker image to golang:1.22.1-alpine3.19.
To confirm the new digest:
```
$ docker pull golang:1.22.1-alpine3.19
1.22.1-alpine3.19: Pulling from library/golang
...
Digest: sha256:fc5e5848529786cf1136563452b33d713d5c60b2c787f6b2a077fa6eeefd9114
...
```
This updates the required minimum protocol version to the maximum
set by dcrwallet 1.8.0. Outbound connections will require the
current protocol version.
This updates the docker image to golang:1.22.0-alpine3.19.
To confirm the new digest:
```
$ docker pull golang:1.22.0-alpine3.19
1.22.0-alpine3.19: Pulling from library/golang
...
Digest: sha256:8e96e6cff6a388c2f70f5f662b64120941fcd7d4b89d62fec87520323a316bd9
...
```
This updates the docker image to golang:1.21.6-alpine3.19.
To confirm the new digest:
```
$ docker pull golang:1.21.6-alpine3.19
1.21.6-alpine3.19: Pulling from library/golang
...
Digest: sha256:fd78f2fb1e49bcf343079bbbb851c936a18fc694df993cbddaa24ace0cc724c5
...
```
This marks the various messages types and commands associated with
version 1 cfilters as deprecated since they are no longer valid and will
eventually be removed whenever a new major version of the wire module is
released..
This updates the docker image to golang:1.21.5-alpine3.18.
To confirm the new digest:
```
$ docker pull golang:1.21.5-alpine3.18
1.21.5-alpine3.18: Pulling from library/golang
...
Digest: sha256:5c1cabd9a3c6851a3e18735a2c133fbd8f67fe37eb3203318b7af2ffd2547095
...
```
If the doneChan is nil, the nil message can be safely ignored. However, this
is still a bug in the caller, so a warning with stacktrace is logged.
If the doneChan is non-nil, panicing is the only reasonable option to prevent
the program continuing on in an unknown state.
The peer code would already panic previously in wire.WriteMessageN for many
queued message types, and introducing a new panic call here should not
introduce any new crashes that would not have occurred before.
This updates the docker image to golang:1.21.4-alpine3.18.
To confirm the new digest:
```
$ docker pull golang:1.21.4-alpine3.18
1.21.4-alpine3.18: Pulling from library/golang
...
Digest: sha256:110b07af87238fbdc5f1df52b00927cf58ce3de358eeeb1854f10a8b5e5e1411
...
```
Hangs at peer disconnect were observed due to the blocking writes on the
buffered stall control channel. This is a new bug that was introduced after
the recent queuing changes that allow more messages to be read at a time.
This modifies the recent concurrent getdata serving logic to immediately
decrement the pending item count and move on to the next requested data
item when an item is not found.
Not only is it more efficient since it means there is no attempt to
acquire the semaphore, it also prevents an issue the new code introduced
where it could incorrectly queue up a nil message leading to a panic.
Currently, each peer only supports one getdata request at a time and the
inbound handler is blocked until all of the requested data is served.
This means messages that would otherwise be fast to process, such as
pings, can potentially be delayed for long periods of time which is
clearly not ideal.
Moreover, the existing behavior means that it is theoretically possible
for a pair of peers to experience a situation where neither one can make
progress because they're both waiting on each other to serve each other
data which then would ultimately result in hitting idle timeouts and
disconnection.
In practice, the aforementioned live lock situation basically never
happens currently due to a variety of other factors such as duplicate
request filtering and not notifying peers about inventory they are known
to have. However, the combination of factors that prevent the situation
will not necessarily apply to newer data types such as those for
mesh-based mixing.
The aforementioned blocking behavior is a holdover from very early
network code that relied on it once upon a time, but is no longer
relevant.
Thus, to improve overall throughput and address the root of the
aforementioned concerns, this changes the semantics to serve getdata
requests asynchronously so other inbound messages can be processed
concurrently. This means the remote peer is then free to send other
messages while waiting for the requested data to be served.
Next, limits to the amount of concurrent getdata requests and the total
maximum number of pending individual data item requests are now imposed
in order to prevent peers from be able to consume copious amounts of
memory and other malicious behavior this change would otherwise allow.
The limits are enforced such that peers may now mix and match
simultaneous getdata requests for varying amounts of data items so long
as they do not exceed the maximum number of allowed simultaneous pending
getdata messages or the maximum number of total overall pending
individual data item requests.
This approach of applying the limits on both dimensions offers more
flexibility and the potential for future efficiency gains while still
keeping memory usage bounded to reasonable limits and protecting against
other malicious behavior.
This change a few cases that log the peer to use the server peer instead
of the underlying peer from the peer package. This doesn't change the
output in any way, but it is more consistent with the vast majority of
other instances. It also preferable since it ensures consistent logging
output if a custom stringer is ever implemented on server peers.
Currently the sync manager maintains additional state per peer in an
internal struct that wraps a base/common peer as well as a mapping keyed
by that base/common peer. The internal wrapped peer is then queried
each time it is needed. This leads to code that is harder to reason
about and can fail to lookup the necessary state in some hard to hit
corner cases.
With that in mind, this modifies the sync manager semantics to instead
export the wrapped peer and require the caller to provide that wrapped
peer in all of its APIs directly. The server then creates and stores
the wrapped peer instance at connection time and passes it to the sync
manager.
The end result is the code is easier to reason about and resolves the
aforementioned hard to hit corner cases since it is no longer possible
for the sync manager to ever have access to a peer without the
associated extra state.
This switches the various subsystems over to use a new pattern that
consolidates the waitgroup logic in a single location.
This pattern is easier to reason about and less error prone since it's
trivial to see at a glance that the calls to Done are happening as
intended versus having to chase them down all over the code.
This modifies the logic in several Run methods to block until the
context is cancelled directly in the Run method instead of launching a
separate goroutine for that purpose.
This approach is preferred since it provides the same functionality
without additional long-running goroutines.
This updates the docker image to golang:1.21.3-alpine3.18.
To confirm the new digest:
```
$ docker pull golang:1.21.3-alpine3.18
1.21.3-alpine3.18: Pulling from library/golang
...
Digest: sha256:926f7f7e1ab8509b4e91d5ec6d5916ebb45155b0c8920291ba9f361d65385806
...
```
This updates the docker image to golang:1.21.2-alpine3.18.
To confirm the new digest:
```
$ docker pull golang:1.21.2-alpine3.18
1.21.2-alpine3.18: Pulling from library/golang
...
Digest: sha256:a5d901a53f906be8dd00c6274ffce633b1873a144dd17c6e8293745695740f07
...
```
Since it is impossible to calculate the necessary values without
breaking the ECDLP, this adds an invented signature to exercise the
branch of the RecoverCompact function that involves the case when the
original X coordinate of the random point is greater than the group
order and therefore has the overflow bit set.
The result is raising the test coverage from 99.2% to 99.6%.
The profiling server typically shouldn't be exposed to the public, so
this doesn't make a huge difference, but it's still good practice for
HTTP servers to have read timeouts.
This updates the sampleconfig package to make use of Go's embed
functionality introduced in Go 1.16 which is acceptable since the
containing module requires Go 1.19.
Embedded files are preferable because they bring the benefits of both
external files in the repository that are easier to work with for
external tools and the ability to access their content programmatically
without having to deal with the various issues typically brought about
by programmatically accessing external files.
Also, when this was last updated to change the exported variable for
dcrd's sample config file over to a function (so it can't be mutated and
the implementation details can be changed if needed), the case for
dcrctl was missed. Moreover, the existence of both configs makes the
func name FileContents ambiguous.
Unfortunately, those things can't be changed now without causing a major
module version bump to the main dcrd module which we really want to
avoid.
So, in order to address those things without needing a major module
version bump, this deprecates the FileContents func and
DcrctlSampleConfig variable and introduces two new functions named Dcrd
and Dcrctl that return the respective embedded sample configs.
This cleans up the handling of internal errors in the RPC server to be
more consistent and use the errors themselves as opposed to their
stringized form.
There are far more instances of already having an error to pass along
versus the ones that generate new errors at the call site. Accepting
the errors directly results in less noise and also makes it harder to
misuse.
This updates the docker image to golang:1.21.1-alpine3.18.
To confirm the new digest:
```
$ docker pull golang:1.21.1-alpine3.18
1.21.1-alpine3.18: Pulling from library/golang
...
Digest: sha256:96634e55b363cb93d39f78fb18aa64abc7f96d372c176660d7b8b6118939d97b
...
```
Now that the target difficulty is calculated every block as opposed to
on an interval, the logic in the getnetworkhashps RPC that treated a
negative number of blocks as a signal to calculate back to the most
recent difficulty change no longer makes sense.
Thus, this updates the getnetworkhashps RPC to ignore negative values
so that the default number of blocks is used instead.
It also updates the RPC server help description accordingly to remove
mention of the previous behavior.
This updates all remaining cases of unwrapped errors in fmt.Errorf calls
to wrap the underlying errors with the %w format verb to ensure they
work nicely with errors.Is and errors.As.
This removes the isTreasuryEnabled paramter from the blockchain
getStakeBaseAmounts func since it is no longer used and updates the only
caller accordingly.
This removes the parent paramter from the LogBlockHeight method on
the internal blockchain progress logger since it is no longer used and
updates all callers accordingly.
This updates the docker image to golang:1.21.0-alpine3.18.
To confirm the new digest:
```
$ docker pull golang:1.21.0-alpine3.18
...
1.21.0-alpine3.18: Pulling from library/golang
...
Digest: sha256:445f34008a77b0b98bf1821bf7ef5e37bb63cc42d22ee7c21cc17041070d134f
...
```
