-
Notifications
You must be signed in to change notification settings - Fork 35.6k
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
Cblockstore class #1429
Closed
Closed
Cblockstore class #1429
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
The goal is for p2p code/wallet to only get information/communicate information about the blockchain through CHub, giving Bitcoin a much more clearly-defined structure and allowing for the removal of a ton of the current global mess.
Replacing ProcessBlock with EmitBlock, and creating callbacks for CommitBlock.
Also rename NotifyBlocksChanged to NotifyNewBlock and remove from the uiInterface signals list. This removes some functionality, but NofiyBlocksChanged was not used anyway, so it shouldn't matter. That said, if it is ever needed, it would be fairly trivial to add a new callback for it in CHub.
Replace ProcessAlert with calls to EmitAlert and create callbacks for CommitAlert.
There was no reason to use CDataStream as the transaction was already being serialized/deserialized several times, with this change, transactions coming in over network are deserialized once when received, and then only reserialized in the call to RelayMessage, which will be called in a callback thread, not blocking cs_main.
* This removes not only CTransaction::AcceptToMemoryPool, but also CMerkleTx::AcceptToMemoryPool. It also moves CWalletTx::AcceptWalletTransaction to wallet.cpp * This adds a fCheckInputs flag to EmitTransaction, which is similar to the fCheckInputs flag to AcceptToMemoryPool, however, it has stricter guidlines that it should only be set "when transaction is a supporting tx for one of our own." Additionally, "fCheckInputs is ignored (and set to true) if !IsInitialBlockDownload() && !fClient" As a part of these guidelines, CWalletTx::AcceptWalletTransaction calls EmitTransaction with fCheckInputs set to true (the default) on the final transaction, whereas it used to call with fCheckInputs set to false. This has the important side-effect of allowing wallet- generated transactions to end up getting AddOrphanTx'd. However, if a supporting transaction to one of our own had previously been AddOrphanTx'd, it would immediately be added to memory pool as it is "a supporting tx for one of our own" and thus is re-added with fCheckInputs=false. Note that the possibility of a wallet transaction getting AddOrphanTx'd is very low, and should only happen if a) a transaction's input is a generate and we are missing that block (note that no transactions should be generated with a generation input if we don't have that block anyway). b) We match the !IsInitialBlockDownload() && !fClient check, are not caught up to the latest block, and an input is in a block we do not yet have (possible after the last checkpoint). This situation is temporary and should resolve itself once we catch up (though AddOrphanTx'd transactions may be permanently orphaned). Largely, these guidelines are there because there is no reason to add a transaction without checking its inputs, as we have those inputs available, and checking them as any other transaction would provides additional sanity-checks. * A second EmitTransaction was added with tx of type CMerkleTx. This keeps behavior of CMerkleTx::AcceptToMemoryPool the same in fClient mode. Note that new behavior was invented for CHub::EmitTransaction(CTransaction&...) in fClient mode, namely that ClientConnectInputs is only checked if fCheckInputs is true. This was chosen to make emitting a transaction possible in fClient mode even if its inputs are not available, but could be changed if support for that is not needed when fClient mode is actually implemented.
Note that this changes the way the GUI shows coinbases of users: it now shows them only after the first non-orphan block based on the generating block, instead of after the first block based on the generating one period.
This needs rebasing, and Im not going to keep rebasing this stuff without any interest in eventually merging. If it ever gets interest, I may reopen. |
suprnurd
pushed a commit
to chaincoin-legacy/chaincoin
that referenced
this pull request
Dec 5, 2017
* clear trafficgraph on clear button click * set default sample height set default sample height so after clearing traffic graph have some scale * reduce available traffic graph ranges, add optimized graph data storage reduce available traffic graph ranges to 10 (5m,10m,15m,30m,1h,2h,3h,6h,12h,24h), store graph data so range change is possible, data storage contains only necessary data to create graphs for all supported ranges eg. for 10m range storage only half of 10m samples - the second half is calculated from 5m range samples, encapsulate all traffic graph related data into one class * code formatting corrections
lateminer
pushed a commit
to lateminer/bitcoin
that referenced
this pull request
Jan 22, 2019
…itcoin#1429) * Refactor CheckFinalTx() Combine the two CheckFinalTx() from main.cpp and txadmission.cpp and keep it in txadmission.cpp. * Exetend CTransactionRef into CheckFinalTx() and IsFinalTx() * Consolidate CheckSequenceLocks() Remove CheckSequenceLocks() from validation.cpp and combine with the one in txadmission.cpp. They are both essentially the same except they potentialy use a different CCoinsViewMemPool. * Extend CTransactionRef to CheckSequenceLocks() * Extend CTransactionRef to CalculateSequenceLocks() * Extend CTransactionRef to SequenceLocks() * fix qt issues with CheckFinalTx()
lateminer
pushed a commit
to lateminer/bitcoin
that referenced
this pull request
May 6, 2020
0f0ccba [GUI] Dark theme, inactive icons color fix. (furszy) Pull request description: Fixing inactive icons colors for the dark theme. ACKs for top commit: random-zebra: ACK 0f0ccba Fuzzbawls: utACK 0f0ccba Tree-SHA512: cbe73b4debd8867492cea7841e773feaf0e6d0ea3d5963dbb9c84d00310a0de1d44d997267807c382a3f4cd2d83a2f7ac593dc7845c939418e9053c2d0bc7326
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This is based on #1408 and gives a preview of the goal of the rebase as a whole. It provides a CBlockStore class to store the block chain and allows CHub to call it and returns data to CHub. If it gets merged, CTxMemPool will be adapted to call CBlockStore functions to get info on previous transactions, and a CAlertStorage class will be added.
I would prefer to not do callbacks from CBlockStore, but I found that cleaner than returning a list of blocks committed (as each call to EmitBlock can commit any number of blocks) through many of the block acceptance functions and back to CHub::EmitBlock, buf if that design is preferred, its not hard to do that.
In general, though CBlockStore effectively turns several CHub functions into NOOPs, I prefer using a CHub as a convenience class so that CWallet/P2P client don't have to know something about CBlockStore and CTxMemPool and CAlertStore, but only needs to know one API. It also removes the need to duplicate much of the code to deal with callback threads in the storage classes.
Obviously this does little actual abstraction, but just creates the class and moves functions from CBlock, if it gets merged, things like mapBlockIndex will get moved into CBlockStore.