Sync with Upstream#1
Open
2a5A1Ghu1 wants to merge 1166 commits intotheohmproject:masterfrom
Open
Conversation
psbt: decode keytype as compact size
Sending RPC requests through unix sockets
commit 0b2998b Author: cec489 <173723251+cec489@users.noreply.github.com> Date: Mon Jun 24 20:01:13 2024 +0000 A cleaner fix is to set the startTime in the server Start() function which is where the server is actually started. commit ae6c125 Author: cec489 <173723251+cec489@users.noreply.github.com> Date: Mon Jun 24 19:15:23 2024 +0000 Fix the btcctl uptime command by moving the setting of startupTime
This change lets us test that we don't attempt to delete open files with unit tests. On Windows this behavior is not allowed which results in an error but on linux and osx it's allowed. To better test Windows compatibilty adding this explicit check in is useful.
This check let's us ensure that attempting to delete open files are caught during unit tests.
The existing file close code is refactored out into it's own method closeFile() so that it can be reused elsewhere.
The block files may be open when deleteFile is called. This resulted in files not being deleted and erroring out on windows. Properly closing the files closing the files avoids this error.
ffldb: close block files
Signed-off-by: linghuying <1599935829@qq.com>
mod+rpcserver: bump to latest version of btcec
It is undefined behavior if we directly use the value from a Get call after the transaction has completed.
blockchain: copy utxo status bytes to avoid UB
Signed-off-by: lencap <techgeek@189.cn>
synchronize dependencies
Updated btcd dependency of btcutil to address CVE-2024-34478
wire: check TXID length before creating outpoint
rpcclient: signet support
Fixes #2224 and lightningnetwork/lnd#9053. Depending on the version of Bitcoin Core, the "warnings" field in the response to getnetworkinfo is either a single string value or an array of strings. We can easily parse those two variants with a custom type that implements an UnmarshalJSON method.
btcjson: turn warnings into StringOrArray type
Signed-off-by: huochexizhan <huochexizhan@outlook.com>
Formatting code with gofmt
chore: fix some comments
…chnorr btcec/schnorr: fix incorrect comment about nonce generation
In this commit, we remove the localhost-only restriction for sync peer candidates on regtest and simnet. Previously, isSyncCandidate rejected any regtest peer not on 127.0.0.1 or localhost, which prevented IBD when nodes run in Docker containers on bridge networks (e.g. 172.18.0.x). We also replace fragile pointer-equality checks against global chaincfg params with value-based Name field comparisons, and extend the exception to simnet since it has the same local-only usage pattern.
Add a test verifying that isSyncCandidate accepts peers from any address on regtest, including Docker bridge IPs, remote IPs, and IPv6.
Revert MaxMessagePayload to 32MB and introduce MaxProtocolMessageLength (~4MB) for p2p network message size enforcement. This mirrors Bitcoin Core's separation between MAX_SIZE (32MB serialization bound) and MAX_PROTOCOL_MESSAGE_LENGTH (~4MB network limit) introduced in bitcoin/bitcoin#5843. The previous commit reduced MaxMessagePayload to 4MB, but that constant is also used as a serialization bound for deriving maxTxInPerMessage, maxTxOutPerMessage, and variable-length string limits in contexts beyond network messages (e.g. database deserialization via MsgTx.Deserialize). While consensus limits keep real values well below the 4MB-derived bounds, conflating the two constants is architecturally incorrect and diverges from Bitcoin Core's design. The new MaxProtocolMessageLength is now enforced in all four network read/write paths: WriteMessageN, WriteMessageWithEncodingN, ReadMessageWithEncodingN, and ReadV2MessageN (which previously had no overall message size check).
netsync: allow sync with non localhost peers
treap, ffldb: add treapNodePool
Add a test case that passes a 16-byte IPv4-mapped IPv6 address (::ffff:127.0.0.1) to NetAddressV2FromBytes and asserts that it is recognized as IPv4 with networkID 0x01, not IPv6 with 0x02.
Go's net.ParseIP stores IPv4 addresses as 16-byte IPv4-mapped IPv6 addresses (::ffff:x.x.x.x). NetAddressV2FromBytes dispatches on address length, so these 16-byte addresses were incorrectly matched as IPv6 and serialized with networkID 0x02 (IPv6) instead of 0x01 (IPv4). BIP-155 doesn't forbid this, but Bitcoin Core silently drops them anyway (undocumented, naturally). Detect IPv4-mapped IPv6 addresses and extract the 4-byte IPv4 address with the correct networkID.
Since btcwallet now supports regtest, we add the default port `18332`. Now `--wallet` command works on regtest.
main: add regtest port for btcwallet
…-ipv6 wire: don't wrap ipv4 in ipv6 addresses
As we introduced a new MaxProtocolMessageLength, MsgReject max size should also be lowered to MaxProtocolMessageLength. If this isn't lowered and if we ever have a MsgReject message that is bigger than MaxProtocolMessageLength, then the MaxPayloadLength() check on the message will pass but it won't serialize in functions WriteMessageWithEncodingN() and WriteV2MessageN() as both of these functions have a separate check that each message isn't greater than MaxProtocolMessageLength.
wire: separate protocol message limit from serialization bound
…-message-len-on-msg-reject wire: use maxprotocol message len on msg reject
This commit replaces the parsing of a JSON string with a simple prefix/suffix replacement of the quotes. That is much faster than allocating memory for a JSON parser. Where possible, we also directly decode the hex with a decoder to further reduce the number of allocations.
In this commit, we fix a policy-level divergence with Bitcoin Core when handling OP_CODESEPARATOR inside unexecuted OP_IF branches in non-segwit scripts with the ScriptVerifyConstScriptCode flag. Bitcoin Core's EvalScript (interpreter.cpp:474-476) places the SCRIPT_VERIFY_CONST_SCRIPTCODE check for OP_CODESEPARATOR before the fExec branch-execution gate, causing it to fire unconditionally on every OP_CODESEPARATOR encountered during script iteration -- even inside OP_FALSE OP_IF ... OP_ENDIF envelopes. Previously, btcd's equivalent check lived inside the opcodeCodeSeparator handler, which was never reached for opcodes in unexecuted branches due to the early return in executeOpcode that skips non-conditional opcodes when isBranchExecuting() is false. This meant a script like: OP_FALSE OP_IF OP_CODESEPARATOR OP_ENDIF <validation> would be rejected by Bitcoin Core's mempool but accepted by btcd's. The fix moves the check before the branch-execution gate in executeOpcode, matching Bitcoin Core's structure. This follows the existing pattern in btcd where isOpcodeDisabled and isOpcodeAlwaysIllegal checks already fire regardless of branch execution state. Note: SCRIPT_VERIFY_CONST_SCRIPTCODE is purely a policy flag (included in STANDARD_SCRIPT_VERIFY_FLAGS but not MANDATORY_SCRIPT_VERIFY_FLAGS), so this was not a consensus divergence. Both implementations would accept such transactions if mined in a block. Found via differential fuzzing by Bruno from bitcoinfuzz.
Add support for newly named Bitcoin Core script-test result tokens and skip taproot placeholder rows that are already covered by TestTaprootReferenceTests.
Bitcoin Core's tx_valid vectors now specify flags to exclude from the full script-flag set. Apply that parser directly in TestTxValidTests.
Handle BADTX sanity cases while keeping tx_invalid on Bitcoin Core's included-flags convention.
Updated from Bitcoin Core master (e32bc7f817e7adeffef22a985bf8dbd4aa3e08d8), file src/test/data/script_tests.json.
Updated from Bitcoin Core master (e32bc7f817e7adeffef22a985bf8dbd4aa3e08d8), file src/test/data/tx_valid.json.
Updated from Bitcoin Core master (e32bc7f817e7adeffef22a985bf8dbd4aa3e08d8), file src/test/data/tx_invalid.json.
The refreshed Bitcoin Core script reference tests expect witness clean-stack failures to report CLEANSTACK rather than a generic EVAL_FALSE result.
The refreshed Bitcoin Core script reference tests cover cases where an empty CHECKSIG input must still fail pubkey encoding checks before the interpreter falls back to a generic false result.
Both NewEngine and GetWitnessSigOpCount used sigScript[1:] (a raw byte suffix of the scriptSig) to identify the candidate redeem script for nested P2SH witness detection. GetPreciseSigOpCount and the existing P2SH execution path already get the redeem script as the final pushed element of the push-only scriptSig (via finalOpcodeData and savedFirstStack[len-1] respectively). This commit consolidates the nested-witness detection sites to use finalOpcodeData(0, scriptSig) so all three places agree on what the redeem script is. As a side effect of using the actual redeem script for detection, the len(witness) != 0 precondition in NewEngine becomes redundant — the redeem script's shape alone determines whether the spend is nested witness, and verifyWitnessProgram already enforces the required witness-stack shape downstream.
Extract the nested P2SH analysis from CalcScriptInfo into a dedicated calcP2SHScriptInfo helper, and switch it to use finalOpcodeData for redeem-script extraction (matching the consolidation in NewEngine and GetWitnessSigOpCount). The helper also threads the inner witness-script expected-input contribution for nested P2WSH spends, which the previous inline code did not account for.
txscript: reject OP_CODESEPARATOR in unexecuted branches for non-segwit
Sync BIP30/BIP34 Handling With Bitcoin Core
rpcclient: add GetTxOutProof{,Async} methods, speed up string parsing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.