Utilize a sync.Pool for *big.Int instances in CryptoRandIntn to avoid
frequent heap allocations. This significantly reduces garbage collection
pressure when randomizing timestamps, amounts, and fees inside loops
(e.g. iterating over forwarding history responses).
Upgrade the randIntn function signature from int to int64 to prevent
unpredictable integer truncation on 32-bit systems (e.g., Raspberry Pi).
This ensures UnixNano timestamps in hideTimestamp and large amounts in
hideAmount do not cause unexpected runtime failures when calling
ForwardingHistory.
- Replace occurrences of `// nolint:lll` with `// nolint:ll` across
files for consistency.
- Reformat multiline strings, comments, and function parameters to
improve clarity and adhere to style guidelines.
- Add `// nolint:ll` comments where necessary to prevent linter
warnings.
In this commit, we update our various firewall interceptors so that they
rely on the session ID passed via gRPC metadata to extract a session ID.
For the PrivacyMapper and RuleEnforcer, these _MUST_ always contain a
session ID and so we error out if one was not found. For the request
logger, the session ID is optional and so we pass it to the new
SessionID field in the AddActionReq - our bbolt actions DB will not make
use of this field on persistence (but our incoming SQL version will).
Update the PrivacyMapDB interface methods to take contexts (both the
methods themselves and the call-back params) and then ensure all
implementations are updated and all call-sites pass contexts through
correctly.
SessionDB is an interface that gives helper methods for how privacy
mapping should be done. A mock for SessionDB is added to save on some
code repetition, the privacy flags functionality is used in a later
test.
We obfuscate pubkeys, channel points and ids entered in configurations.
The channel id lengths for different block heights can be checked with:
```python
len(str(1 << 40 | 2923 << 16 | 30))
len(str(10_000_000 << 40 | 2923 << 16 | 30))
```
In this commit, in the response handlers of the privacy mapper, we
construct new response messages instead of overwriting existing messages
in order to minimize the chances of private data slipping through
accidentally.
Adds amount, timestamp, and channel initiator obfuscation to the two
response handlers `handleFwdHistoryResponse` and
`handleListChannelsResponse`.
In order to preserve privacy and still ensure functioning of algorithms
that rely on the randomized data, a trade-off between randomization and
accuracy needs to be found.
We choose ten minutes for forwarding timestamps as this breaks time
correlation of payments.
The amount obfuscation is chosen to be 5% and applies to the forwarding
amount and channel details to hide balances. We also remove details of
pending HTLCs in channels. Random obfuscation for amounts is chosen here
instead of rounding to have non-deterministic alteration of amounts,
which is especially important for forwardings to also break amount
correlation. Randomly varying around a certain value will statistically
skew averages less than rounding for algorithms that rely on
aggregation of individual data.
The privacy mapper is chosen to accept a randomness input in order to
ensure deterministic testing even when other handlers are changed in the
future.
Adds helper functions to randomize amounts, timestamps, and booleans.
Amounts are randomized based on a percentage and timestamps based on an
absolute scale.
