forked from btcsuite/btcd
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CHAINS-4196 - Fetch upstream 6 24 24 #6
Merged
Merged
Conversation
This file contains 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
On startup when the headers-first mode is off, when receiving the first block, the periodic flush will trigger. The lastflushtime wasn't set which resulted in the flush being triggered on the first block on restart.
* Dockerfile: fix typo * blockchain: fix typos * sample-btcd.conf: fix typos * server: fix typos * txscript: fix typos
Fix some typos
This commit breaks the `maybeAcceptTransaction` into two parts - the first is reading the mempool to validate the transaction, and the relevant logic has been moved into the new method `checkMempoolAcceptance`. The second part is writing to the mempool, and is kept in the method `maybeAcceptTransaction`.
This commit adds bitcoind version 22.0 and 25.0 to our `BackendVersion` set to handle the `testmempoolaccept` RPC calls. A unit test is added to make sure the parser works as expected.
This commit adds a new interface `TxMempool` which defines how other subsystems interact with `TxPool`.
…laccept` This commit creates a `RejectReasonMap` to map the errors returned from `btcd` to bitcoind's `testmempoolaccept` so the `RejectReason` is unified at the RPC level. To make sure the map keys are unique, the error strings are modified in `btcd`.
Also add the `make tidy-module` copied from `lnd`.
support `testmempoolaccept` for both `bitcoind` and `btcd`
This commit makes sure the batch requests are always GCed before sending back the responses for them. In particular, - `removeRequest` didn't remove the item from `batchList`, which is now fixed. - `Send` didn't remove the request from `requestMap`, which is now fixed by using `removeRequest`.
Noticed during ibd that there's a slight overhead for handleBlockchainNotification on mempool/fee estimator updates. Since there's no reason to be looking at this while we're not caught up, return early and avoid the calls.
rpcclient: make sure batch requests are GCed
refactor: add `make help` to display the usage for project Makefile
…t-flush-time-on-initconsistentstate blockchain: set the lastflushtime when setting the lastflushhash
Calling t.Fatal inside db.View makes the test hang on failures. Return the error and call t.Fatal outside of db.View avoids this.
Pruning stale blocks will make the block validation fail for the block that the prune was triggered on as BlockHeightByHash will not return the height for blocks that are not in the main chain. We add a test case to ensure that the test fails in the above case.
* chaincfg: remove unresponsive dnsseed on testnet testnet-seed.bitcoin.schildbach.de is unresponsive and doesn't return any ips. Bitcoin Core has already removed it and we don't also be getting rid of it as well. * chaincfg: add dnsseeds from Sjors Provoost His seeds work well and we don't have any for signet and it's good to replace the lost dns seed on testnet. * chaincfg: remove bad dnsseed (seed.bitcoinstats.com) seed.bitcoinstats.com doesn't respect filter requests even though it's advertised as it does. Plus it often returns nodes that are unreachable. In my testing over the past week, it's been the most unreliable dns seed and since we have plenty of mainnet seeds, it's better to do away with this. I documented my findings for this in a Bitcoin Core issue: bitcoin/bitcoin#29911 * chaincfg: add dnsseed from wiz It's the same infrastructure that mempool . space runs on and has been reliable. The same seed is also included in Bitcoin Core as well.
Signed-off-by: oftenoccur <ezc5@sina.com>
Signed-off-by: MarkDaveny <peicuiping@aliyun.com>
InvalidateBlock() invalidates a given block and marks all its descendents as invalid as well. The active chain tip changes if the invalidated block is part of the best chain.
For debug purposes down the road, log that the node is pruned if it's set to pruned.
This exposes publicly the ability to decode arbitrary-length bech32 strings and return the bech32 version that was used in the encoding. It provides the underlying functionality for both DecodeNoLimit and DecodeGeneric.
This is to mitigate CVE-2017-12842. Along the way, also error when deserializing transactions that have the witness marker flag set but have no witnesses. This matches Bitcoin Core's behaviour initially introduced here bitcoin/bitcoin#14039. Allowing such transactions is benign, but this makes sure that our parsing code matches Core's exactly.
Update standardness rules congruent to Bitcoin Core
blockchain, main: add and fix logs
…ate-block blockchain, fullblocktests, workmath, testhelper: add InvalidateBlock() method to BlockChain
…oned Added DecodeNoLimitGeneric to bech32.go
refactor: set strconv.ParseFloat bitsize to 64
reorganizeChain() used to handle the following: 1: That the blocknodes being disconnected/connected indeed to connect properly without errors. 2: Perform the actual disconnect/connect of the blocknodes. The functionality of 1, the validation that the disconnects/connects can happen without errors are now refactored out into verifyReorganizationValidity. This is an effort made so that ReconsiderBlock() can call verifyReorganizationValidity and set the block status of the reconsidered chain and return nil even when an error returns as it's ok to get an error when reconsidering an invalid branch.
ReconsiderBlock reconsiders the validity of the block for the passed in blockhash. The behavior of the function mimics that of Bitcoin Core. The invalid status of the block nodes are reset and if the chaintip that is being reconsidered has more cumulative work, then we'll validate the blocks and reorganize to it. If the cumulative work is lesser than the current active chain tip, then nothing else will be done.
Signed-off-by: coderwander <770732124@qq.com>
blockchain: Add ReconsiderBlock()
invalidateblock and reconsiderblock are added to the rpcclient package and an integration test is added to test the added functions.
The rpc calls and the rpchelp is added for the invalidateblock and reconsiderblock methods on BlockChain.
main, rpcclient, integration: add rpccalls for invalidate and reconsiderblock
build: bump version to v0.24.2-beta
charlie-paxos
approved these changes
Jun 25, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Merge upstream master to include this fix for v27
btcsuite#2142
Cmds to create this PR (direct from my terminal's history)