In this commit, we ensure hash function parameters are consistent with
filter size to avoid unnecessary operations. A filter with no capacity
doesn't actually require any hash functions, so we can cut that loop
short.
In this commit, we add a new function, `ScriptTemplate` to make the
process of making custom Bitcoin scripts a bit less verbose.
ScriptTemplate processes a script template with parameters and returns the
corresponding script bytes. This functions allows Bitcoin scripts to be
created using a DSL-like syntax, based on Go's templating system.
An example of a simple p2pkh template would be:
`OP_DUP OP_HASH160 0x14e8948c7afa71b6e6fad621256474b5959e0305 OP_EQUALVERIFY OP_CHECKSIG`
Strings that have the `0x` prefix are assumed to byte strings to be pushed
ontop of the stack. Integers can be passed as normal. If a value can't be
parsed as an integer, then it's assume that it's a byte slice without the 0x
prefix.
Normal go template operations can be used as well. The params argument
houses paramters to pass into the script, for example a local variable
storing a computed public key.
The preivous usage of two channels - by piping them together to create a
semaphore effect, is difficult to follow and prone to bugs. This commit
now refactors the method to explicitly implement a semaphore.
Prior to this change, we would allow at max 3 concurrent goroutines -
this is now bumped to 5.
In this commit, we add more detail to the invalid tapscript merkle proof
error. Before this commit, the error was blank, making such a case hard
to debug. We'll now log the expected witness program, what we derived,
and also the passed in tapscript root.
In this commit, we reduce the size of the v2transport module by shedding
the dep on the wire package. This allows us to only depend on btcec/v2,
which itself is a sub module, instead of the entire btcd module.
In this commit, we refactor the v2 -> v1 downgrade logic to: simplify
the code in the server for reconnection, use a functional option to
avoid breaking the connmgr API, and we also encapsulate the downgrade
state in a new struct so it can be re-used elsewhere.
This commit adds a new boolean field, `V2Connection`, to the
`getpeerinfo` RPC result. This field indicates whether the connection
to the peer is using the v2 encrypted transport protocol.
The `peer.StatsSnap` struct is updated to include this `V2Connection`
field, which is populated based on the `UsingV2Conn` field in the peer's
configuration. The `btcjson.GetPeerInfoResult` struct is also updated
to include the corresponding JSON field `v2_connection`. Finally, the
`handleGetPeerInfo` RPC handler is modified to copy this value from the
peer's stats snapshot into the RPC response.
When ShouldDowngradeToV1() returns true, we'll:
- mark in pendingReconnects that we should attempt v1 bitcoin p2p transport
when the connmgr successfully re-establishes the outbound TCP connection.
- set a bit on the associated *serverPeer that will cause us to tell the
connmgr to reconnect. This is needed because not all outbound peers are
permanent and we might otherwise not reconnect to them if the initial v2
transport negotiation failed.
This commit introduces detailed logging throughout the v2 transport
implementation using the `btclog` package. Logging has been added to
key functions to provide better visibility into the handshake process,
packet encryption/decryption, and underlying network operations.
Log levels are used as follows:
- Debug: High-level steps within functions (e.g., starting handshake,
creating ciphers, sending/receiving major components).
- Trace: Detailed internal state, cryptographic operations, byte-level
data (e.g., derived keys, intermediate values, raw bytes sent/received,
loop iterations).
- Info: Significant state changes or events (e.g., reverting to v1).
- Warn/Error/Critical: Issues encountered during operation.
Logging includes variable states using the format "key=%v" for easier
parsing and debugging. This enhances observability during connection
establishment and data transfer using the v2 transport protocol.
