Skip to content
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 126 commits into from
Jun 25, 2024
Merged

Conversation

gitteri
Copy link

@gitteri gitteri commented Jun 24, 2024

Merge upstream master to include this fix for v27
btcsuite#2142

Cmds to create this PR (direct from my terminal's history)

  417  cd $PAXOS_HOME
  418  git clone git@github.com:paxosglobal/btcd.git
  419  cd btcd
  420  git remote -v
  421  git remote add upstream https://github.com/btcsuite/btcd.git
  422  git remote -v
  424  git checkout -b fetch-upstream-6-24-24
  425  git fetch upstream
  426  git merge upstream/master
  427  vim rpcclient/infrastructure.go // this is the one file that had a conflict and the reason we have this fork
  428  git status
  429  git add rpcclient/infrastructure.go
  430  git commit -m "merge master 6-24-24"
  431  git push

kcalvinalvin and others added 30 commits January 3, 2024 14:24
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
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.
kcalvinalvin and others added 27 commits April 23, 2024 11:11
* 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
…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>
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
@gitteri gitteri merged commit e23a7f6 into master Jun 25, 2024
@gitteri gitteri deleted the fetch-upstream-6-24-24 branch June 25, 2024 17:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.