-
Notifications
You must be signed in to change notification settings - Fork 36.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
Refactor: Start to separate wallet from node #14437
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
Added 2 more small commits d0af21f -> a10e919 (pr/wchain.1 -> pr/wchain.2, compare) from #10973 to fix the thread safety warnings (which are harmless but treated like errors). |
This adds a class named TransactionPicker and introduces a new namespace proposer in its own directory. I sort of got fed up of the untestability of bitcoin and that everything is intertwined with each other directly. In order to propose a block I need to build one which is I have to (1) pick transactions (2) put a coinstake transaction (includes block height, signature, reward output) (3) sign the thing. Picking transactions is already implemented in bitcoin but it's well buried inside CBlockAssembler which does too many things at once for my taste + deals with that horrendous CBlockTemplate (see comment in BlockAssemblerAdapter in the source). Since I want my Proposer to be testable and (1+2+3) are essentially simple operations I want the code to be simple. So here is the part which performs 1, by delegating to bitcoin's block assembler (for now). This way I do not have to change the block assembler or overwrite the coinbase transaction in the block template. I would be interested in hearing your thoughts about my approach, as I intend to follow it with everything I do from now on. Maybe you are fundamentally opposed to virtual methods or whatever. In bitcoin there have been small efforts to extract things into Interfaces (CValidationInterface for instance) also. More recent work is on separating wallet and node and also here they start to create interfaces (bitcoin/bitcoin#14437, src/interfaces).
Concept ACK 👍 |
Is it intentional that the interfaces code uses a different coding style than the rest of the code? If so, does this need documenting somewhere, and if not, can it be converted? |
This PR does not seem to compile when rebased on |
>>> Inspired by bitcoin#11864 (+bitcoin#10784) Since CreateTransaction still needs cs_main we need to obtain both locks in FundTransaction, to preserve locking order. After introducing the chain interface (bitcoin#14437) we can change the LOCK2(cs_main, cs_wallet) to just LOCK(cs_wallet)
>>> Inspired by bitcoin#11864 (+bitcoin#10784) Since CreateTransaction still needs cs_main we need to obtain both locks in FundTransaction, to preserve locking order. After introducing the chain interface (bitcoin#14437) we can change the LOCK2(cs_main, cs_wallet) to just LOCK(cs_wallet)
>>> Inspired by bitcoin#11864 (+bitcoin#10784) Since CreateTransaction still needs cs_main we need to obtain both locks in FundTransaction, to preserve locking order. After introducing the chain interface (bitcoin#14437) we can change the LOCK2(cs_main, cs_wallet) to just LOCK(cs_wallet)
>>> Inspired by bitcoin#11864 (+bitcoin#10784) Since CreateTransaction still needs cs_main we need to obtain both locks in FundTransaction, to preserve locking order. After introducing the chain interface (bitcoin#14437) we can change the LOCK2(cs_main, cs_wallet) to just LOCK(cs_wallet)
>>> Inspired by bitcoin#11864 (+bitcoin#10784) Since CreateTransaction still needs cs_main we need to obtain both locks in FundTransaction, to preserve locking order. After introducing the chain interface (bitcoin#14437) we can change the LOCK2(cs_main, cs_wallet) to just LOCK(cs_wallet)
>>> Inspired by bitcoin#11864 (+bitcoin#10784) Since CreateTransaction still needs cs_main we need to obtain both locks in FundTransaction, to preserve locking order. After introducing the chain interface (bitcoin#14437) we can change the LOCK2(cs_main, cs_wallet) to just LOCK(cs_wallet)
>>> Inspired by bitcoin#11864 (+bitcoin#10784) Since CreateTransaction still needs cs_main we need to obtain both locks in FundTransaction, to preserve locking order. After introducing the chain interface (bitcoin#14437) we can change the LOCK2(cs_main, cs_wallet) to just LOCK(cs_wallet)
>>> Inspired by bitcoin#11864 (+bitcoin#10784) Since CreateTransaction still needs cs_main we need to obtain both locks in FundTransaction, to preserve locking order. After introducing the chain interface (bitcoin#14437) we can change the LOCK2(cs_main, cs_wallet) to just LOCK(cs_wallet)
>>> Inspired by bitcoin#11864 (+bitcoin#10784) Since CreateTransaction still needs cs_main we need to obtain both locks in FundTransaction, to preserve locking order. After introducing the chain interface (bitcoin#14437) we can change the LOCK2(cs_main, cs_wallet) to just LOCK(cs_wallet)
>>> Inspired by bitcoin#11864 (+bitcoin#10784) Since CreateTransaction still needs cs_main we need to obtain both locks in FundTransaction, to preserve locking order. After introducing the chain interface (bitcoin#14437) we can change the LOCK2(cs_main, cs_wallet) to just LOCK(cs_wallet)
>>> Inspired by bitcoin#11864 (+bitcoin#10784) Since CreateTransaction still needs cs_main we need to obtain both locks in FundTransaction, to preserve locking order. After introducing the chain interface (bitcoin#14437) we can change the LOCK2(cs_main, cs_wallet) to just LOCK(cs_wallet)
>>> Inspired by bitcoin#11864 (+bitcoin#10784) Since CreateTransaction still needs cs_main we need to obtain both locks in FundTransaction, to preserve locking order. After introducing the chain interface (bitcoin#14437) we can change the LOCK2(cs_main, cs_wallet) to just LOCK(cs_wallet)
>>> Inspired by bitcoin#11864 (+bitcoin#10784) Since CreateTransaction still needs cs_main we need to obtain both locks in FundTransaction, to preserve locking order. After introducing the chain interface (bitcoin#14437) we can change the LOCK2(cs_main, cs_wallet) to just LOCK(cs_wallet)
4be3b76 refactor: Cleanup walletinitinterface.h (Hennadii Stepanov) Pull request description: Forward declarations of `CScheduler` and `CRPCTable` classes are no longer needed after ea961c3 (bitcoin#14437) commit. Including `<string>` is no longer needed after 4d4185a (bitcoin#13190) commit. ACKs for top commit: theStack: ACK 4be3b76 promag: ACK 4be3b76. kristapsk: ACK 4be3b76 (tested that it builds) Tree-SHA512: 5ed72e3deda3d7c7fb698a1a11db76199727e6c570dfc78422690dbda9a92af32e1913920062dd3c9f618095e7498c219ff9c145a4c151486865ebeaa20a1d3c
4be3b76 refactor: Cleanup walletinitinterface.h (Hennadii Stepanov) Pull request description: Forward declarations of `CScheduler` and `CRPCTable` classes are no longer needed after ea961c3 (bitcoin#14437) commit. Including `<string>` is no longer needed after 4d4185a (bitcoin#13190) commit. ACKs for top commit: theStack: ACK 4be3b76 promag: ACK 4be3b76. kristapsk: ACK 4be3b76 (tested that it builds) Tree-SHA512: 5ed72e3deda3d7c7fb698a1a11db76199727e6c570dfc78422690dbda9a92af32e1913920062dd3c9f618095e7498c219ff9c145a4c151486865ebeaa20a1d3c
4be3b76 refactor: Cleanup walletinitinterface.h (Hennadii Stepanov) Pull request description: Forward declarations of `CScheduler` and `CRPCTable` classes are no longer needed after ea961c3 (bitcoin#14437) commit. Including `<string>` is no longer needed after 4d4185a (bitcoin#13190) commit. ACKs for top commit: theStack: ACK 4be3b76 promag: ACK 4be3b76. kristapsk: ACK 4be3b76 (tested that it builds) Tree-SHA512: 5ed72e3deda3d7c7fb698a1a11db76199727e6c570dfc78422690dbda9a92af32e1913920062dd3c9f618095e7498c219ff9c145a4c151486865ebeaa20a1d3c
This creates an incomplete
Chain
interface insrc/interfaces/
and begins to update wallet code to use it.#10973 builds on this, changing the wallet to use the new interface to access chain state, instead of using CBlockIndex pointers and global variables like
chainActive
.