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

Cblockstore class #1429

Closed
wants to merge 22 commits into from
Closed

Conversation

TheBlueMatt
Copy link
Contributor

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.

Matt Corallo added 22 commits June 10, 2012 22:20
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.
@TheBlueMatt
Copy link
Contributor Author

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.

@TheBlueMatt TheBlueMatt closed this Jul 5, 2012
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
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants