"Unknown transaction type found" in debug.log in p2pool Generate-Txs #1848
Labels
Comments
This was referenced Sep 21, 2012
KolbyML
pushed a commit
to KolbyML/bitcoin
that referenced
this issue
Dec 5, 2020
…alue 288953d [Refactor] Cleaner GetBlockValue implementation (random-zebra) 0d2fc0a [Bug] Align GetBlockValue calls to CreateCoinStake: current height + 1 (random-zebra) Pull request description: This is a known old bug, which was never truly fixed, due to it being harmless (and discovered after the last block-value reduction). The function `GetBlockValue(int nHeight)` returns the block-reward value for a block at a given height (based on a "halving" schedule hardcoded within the function). The issue is that it was being called passing the height of the *previous* block. At some point, one particular call (in `CreateCoinStake`) was changed to use the (correct) current block height, while leaving the wrong one in all other places (including masternode payments/budgets and validation code). This made no real difference with PIVX, as the change was introduced before the last milestone (which increased the block value from 4.5 to 5, rather than reducing it), and, after that, the block value never changed anymore (so it has always been `GetBlockValue(N) == GetBlockValue(N-1)`). But it was an issue for all PIVX forks that had different schedules (or that introduced drastic changes to the masternode/staker-rewards proportions). In bitcoin#967 @CaveSpectre11 gives a complete explanation of the problem (already discussed on a wrong fix attempt in bitcoin#814), and proposes to change only the call in `CreateCoinStake`, aligning it to the (wrong) height (mostly for the sake of consistency and for the benefit of future PIVX forks, as it has no effect on PIVX chain, at his current height). This PR, instead, proposes the opposite solution. Align all other calls, so that the correct height is passed (`pindex->nHeight` during validation, and `pindexPrev->nHeight + 1` when creating a new block). This makes the code consistent with the actual block values on chain. For example, the first-6-masternodes-premine was **not** in the genesis block, but at block 1. Therefore we should have had `60001 * COIN` returned by `GetBlockValue(1)`, not by `GetBlockValue(0)`. - main-net <https://explorer.pivx.link/block/000005504fa4a6766e854b2a2c3f21cd276fd7305b84f416241fd4431acbd12d> - testnet <https://testnet.pivx.link/block/0000081796e8bf7f8047cc84681ceecb64da781e11961da844d0f8b7c13690a5> Thus, to align it with the values on chain (and prevent issues during initial sync) the schedule defined inside `GetBlockValue` is "shifted ahead" by one block. This also refactors `GetBlockValue` to make it more readable. Tested Resyncing from scratch on both testnet and mainnet. Based on top of - [x] bitcoin#1844 just to avoid merge conflicts with the refactoring of `CBudgetManager::FillBlockPayee`. Only the last two commits are new here. ACKs for top commit: furszy: utACK 288953d after rebase. Fuzzbawls: ACK 288953d Tree-SHA512: 684bb9aee09067e459abd2bbcb338e1a93d499e76732043e85a89b607d70fc22a778253426ae14763a26be6b93e60a65cb165368ea8b7dbf77d87c9021b993b8
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
On the "listtransactions" RPC command I get the following errors for all P2Pool txs that send coins to one of my addresses
CWalletTx::GetAmounts: Unknown transaction type found, txid a1450e39bff9771939315ea808676f0054cfec50f41f443c90f4fa4562ed6a30
"version" : 70003
The text was updated successfully, but these errors were encountered: