How to invalidate certain transaction? As node seems stuck with one. #1568
Comments
|
EDIT: As noted elsewhere, a bug has been discovered in Release Candidate 1 of 1.4.0, so miners should not update until there is a new release candidate to address the issue. EDIT 2: See the patch below for a fix to 1.3.0 in the mean time. |
|
Great! Thanks. |
|
Oops, we update to 1.4.0 but the wrong transaction packed into an block which not accept by 1.2.0 staking nodes! So will not collect enough votes for new blocks! @davecgh |
|
Can you provide more details on the exact error you're seeing? I fired up an old 1.2.0 node and am syncing it to the main chain currently to see if I encounter any issues. |
|
@davecgh The new 1.4.0 node will generate block that not acceptable by 1.2.0 since included the mentioned transaction. |
Example that new block not acceptable but wait the old-node-chain to catch up then orphan... |
|
Alright, thanks. So, you guys went back to 1.3.0 for now, right? We'll dig into what's going on the release candidate and get it fixed to put out a new RC. |
|
another |
|
Yes, back to 1.3.0 for now (after resync the old chain T_T ). |
|
|
Is that on a freshly synced v1.3.0? I just created a newly synced 1.3.0 and manually submitted the block to it: |
|
2019-01-18 18:00:27.678 [INF] DCRD: Version 1.3.0+dev (Go version go1.11.4) |
|
Above partial logs including two rejected blocks, all caused by "output aa:0 referenced from transaction bb:0 either does not exist or has already been spent". |
|
v1.4.0-rc1 is shit, please do NOT upgrade or you will get lots of orphan blocks. |
|
As an update, we've tracked down the issue and have a PR open to address it. Thanks to those who reported the issue and helped test the release candidate to discover the issue. This is why there are release candidates. I'll leave this issue open until a new RC is released which addresses it. |
|
@davecgh Thanks for the update. BTW, any temporary patch available to old versions (v1.3) that prevent the node from being stuck on final checks when Logs when stuck: |
|
The following patch will stop that from happening on 1.3.0: diff --git a/mempool/mempool.go b/mempool/mempool.go
index f4ac8846..4915cb73 100644
--- a/mempool/mempool.go
+++ b/mempool/mempool.go
@@ -858,8 +858,22 @@ func (mp *TxPool) maybeAcceptTransaction(tx *dcrutil.Tx, isNew, rateLimit, allow
tx.SetTree(wire.TxTreeStake)
}
- // Reject votes before stake validation height.
isVote := txType == stake.TxTypeSSGen
+ if msgTx.Version >= 2 && !isVote {
+ for _, txIn := range msgTx.TxIn {
+ sequenceNum := txIn.Sequence
+ if sequenceNum&wire.SequenceLockTimeDisabled != 0 {
+ continue
+ }
+
+ str := "violates sequence lock consensus bug"
+ return nil, txRuleError(wire.RejectInvalid, str)
+ }
+ }
+
+ // Reject votes before stake validation height.
stakeValidationHeight := mp.cfg.ChainParams.StakeValidationHeight
if isVote && nextBlockHeight < stakeValidationHeight {
str := fmt.Sprintf("votes are not valid until block height %d (next "+ |
|
Has the patch been working for you? Given that we've tested the it pretty thoroughly, I'm confident that it works properly, but more confirmation is always a good thing. |
|
@davecgh The patch works properly. The v1.3 nodes run continuously ever after. Thank you for your support. |
|
This is resolved by 1.4.0-rc3. |
Cannot create new block template as node (v1.2) stucking at this message. Is newer version resolved this?
The text was updated successfully, but these errors were encountered: