-
Notifications
You must be signed in to change notification settings - Fork 19
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
Conflicted transactions (reopen) #7
Comments
Your transaction (updating "labi") was never confirmed. Instead, the hunter got killed due to staying too long in spawn (i. e., "cash out"). Since this made the pending update transaction invalid, it got marked as conflicted. All seems to be working as intended - do you see an issue with the handling here? (Apart from possibly that miners did not confirm your transaction fast enough or the spawn-death time might be too quick, but those are not issues related to the core client.) |
put this way no, it seems legit, maybe i chose the wrong example, but looking better to what's happening it seems it could be a timing issue, i notice that often the hunter takes 3 blocks instead of 2 for a transaction to go in, and this could be the problem. As i said on the forum the block time generation timing is a problem because often you see two blocks generating in few seconds. the bad thing is that most of the time the enemy got it sooner then me, but this seems to be related with the "slow wallet" problem i reported, it took too much to return the gamestate and process the move while the enemy process sooner (not sure if with higher fee, i should check). But as you say this is another problem. Anyway I'll try to check more about the problem, because i faced some "stuck hunters", and some more problems about wallet balance (and this is a real issue), but... i suppose this is the time for another issue report. About this problem i think you can close the issue and maybe reopen if I find something weird about this subject |
Closing, feel free to reopen if you find more issues here not matching the explanation. |
i have a new stuck transaction (conflicted) between two different hunters, here they are this one died:  and went in conflict with this hunter, that's now stuck since 20 blocks  what's the cause? how can i "unlock" the stuck hunter (that's alive but can't move?) |
this is the other conflicting tx, (when "fi" have been killed) { |
so from what i've understood: "fi" died... and so the "fi" move that was on pending, went in "conflict".. and probably the change of the conflicted "fi" move has been used to generate the "me" move and now "me" is in the limbo, this is a problem to investigate further because can cause players to have zombies in the map (like the user that yesterday reported to be hacked, probably we felt in this same scenario) |
and this is another stuck transaction, but without any evidence of conflicted transaction { even restarting the client (wiping memory pool) didn't sorted any effect... |
a note on the last reported case (the stuck hunter without any conflicted tx involved). It unstuck after exactly 1 hour (a coincidence or a sort of "timeout"?) about the stuck "me" i managed to kill him with a nearby hunter, so i don't know if he would be able unstuck the same way anyway this is something that can cause frustrations among players |
There's no timeout, so the only two reasons why a tx might be stuck temporarily and unstuck later by itself could be a) miners ignoring it for some reason (there's no control we have over that) or b) a bug in the tx relay code (but that seems unlikely as it should affect most transactions in that case and/or be present in upstream Bitcoin as well). Maybe a miner can help us debug this, in case there's some output from his client telling us that it considered the tx unmineworthy for some reason. Regarding the "mi" transaction: I checked it, and it didn't spend change from the "fi" transaction, at least not directly. (The inputs are |
07947ff2da Merge #9: [tests] Fix BOOST_CHECK_THROW macro ec849d9a28 [tests] Fix BOOST_CHECK_THROW macro 31bc9f5a49 Merge #8: Remove unused Homebrew workaround fa042093d1 Remove HomeBrew workaround a523e08ae4 Merge #7: Declare single-argument (non-converting) constructors "explicit" a9e53b38ba Merge #4: Pull upstream 16a1f7f6e9 Merge #3: Pull upstream daf1285af6 Merge pull request #2 from jgarzik/master f32df99e96 Merge branch '2016_04_unicode' into bitcoin 280b191cb1 Merge remote-tracking branch 'jgarzik/master' into bitcoin 2740c4f712 Merge branch '2015_11_escape_plan' into bitcoin git-subtree-dir: src/univalue git-subtree-split: 07947ff2da9ef02a9dfa13346bc5545708e3ebe7
In my wallet "often" i find some "Conflicted" transaction, and most of this happen when i'm fighting (destructing or moving around enemies, coincidence?), looking for info, I checked which tx were conflicting and i found they were some tx that were confirmed few blocks ahead (2 or 3), what's happening there?
Of course this often lead to lose the hunter (so 100 huc) because he missed the action I required (destruct) while the enemy didn't... this is a big problem of course, but what's the cause? there is a bug in the wallet that reuse some coins? Sometimes i receive even errors during my name updates, stating that i'm double spending coins (not sure this relate then to those conflicting transaction because the error seems to pop up less frequently)
I just created some random hunters to test if i can replicate the issue, and i found one, this is my findings (lot of data!):
Conflicted tx:
Status: conflicted with a transaction with 3 confirmations, broadcast through 3 node(s)
Date: 11/01/2017 23:10
Total debit: 101.00000000 HUC
Total credit: -101.00000000 HUC
Net amount: -0.01000000 HUC
Transaction ID: a2c8050e9a17d343460f6e4b29e72e1e1214a846f7fa302e698863007c44bb61
Transaction total size: 403 bytes
Output index: 0
Using ListTransaction i extracted those info about the conflicted tx and the 2 confirmed that caused conflict
{
"account": "",
"address": "H9s3Wkfjfd6FBB8EKzH79LeNK7LUcbeAXm",
"name": "update: labi",
"category": "send",
"amount": 0.00000000,
"vout": 0,
"fee": -0.01000000,
"confirmations": -8,
"trusted": false,
"txid": "a2c8050e9a17d343460f6e4b29e72e1e1214a846f7fa302e698863007c44bb61",
"walletconflicts": [
"55bd74586016dea8027c8c0d51b569e7e5bbeb0d931ea6d104a15a22bf29c086",
"249dea937dc353154abec3f464b656e09a99711a1391b12189ee9cb44c693fe4"
],
"time": 1484172639,
"timereceived": 1484172639,
"bip125-replaceable": "unknown",
"abandoned": false
}
{
"account": "",
"name": "killed: labi",
"category": "killed",
"amount": 0.00000000,
"vout": 1,
"fee": 0.00000000,
"confirmations": 8,
"blockhash": "e696ce60f7e6145f0f2f91a1a8d5d78ae8b26826cecdb26736704c44d8a5efac",
"blockindex": 17,
"blocktime": 1484172636,
"txid": "55bd74586016dea8027c8c0d51b569e7e5bbeb0d931ea6d104a15a22bf29c086",
"walletconflicts": [
"a2c8050e9a17d343460f6e4b29e72e1e1214a846f7fa302e698863007c44bb61"
],
"time": 1484172639,
"timereceived": 1484172688,
"bip125-replaceable": "no",
"abandoned": false
},
{
"account": "",
"address": "HQmVHLGD3AKYbiV3Nu3cE5aRPQyAtMKnqK",
"name": "update: Cep",
"category": "send",
"amount": 0.00000000,
"vout": 0,
"fee": -1.01000000,
"confirmations": 6,
"blockhash": "b216b05586592f383933dd5762e105b314d9c50379d19f73a4ac2844a8951e33",
"blockindex": 1,
"blocktime": 1484172720,
"txid": "249dea937dc353154abec3f464b656e09a99711a1391b12189ee9cb44c693fe4",
"walletconflicts": [
"a2c8050e9a17d343460f6e4b29e72e1e1214a846f7fa302e698863007c44bb61"
],
"time": 1484172711,
"timereceived": 1484172711,
"bip125-replaceable": "no",
"abandoned": false
}
Conflicted Transaction Detail
{
"txid": "a2c8050e9a17d343460f6e4b29e72e1e1214a846f7fa302e698863007c44bb61",
"hash": "a2c8050e9a17d343460f6e4b29e72e1e1214a846f7fa302e698863007c44bb61",
"size": 403,
"vsize": 403,
"version": 28928,
"locktime": 1557211,
"vin": [
{
"txid": "1fbe5c4bd6db40690b18c2ceb2c2b66800d290bb9e432bb920e5970862943c4a",
"vout": 0,
"scriptSig": {
"asm": "3045022100fb85c66d1fe9901d127321b03a995836bf96c839f66dbd3e2338184962da60e6022066f3c820339844c545c4fa6624ce272b0b5a25ce50d4094b6405d26636cc5f10[ALL] 023770a1b31bf5d3924daa22342b7cb3dd7e80c4d3c9cfa02fa51497b2f816af26",
"hex": "483045022100fb85c66d1fe9901d127321b03a995836bf96c839f66dbd3e2338184962da60e6022066f3c820339844c545c4fa6624ce272b0b5a25ce50d4094b6405d26636cc5f100121023770a1b31bf5d3924daa22342b7cb3dd7e80c4d3c9cfa02fa51497b2f816af26"
},
"sequence": 4294967294
},
{
"txid": "f81c18f99e5c5b0a6e332f5d371ee7d5e5a5cfd3c28506281382fefcf85d6186",
"vout": 2,
"scriptSig": {
"asm": "304402206cd673c4fd5d3a22fb2601eb6d28d486ffb8493b2334b2205e603c89cd66da85022063b9d89926657fdc021a8e0bdc48b3d8416acea81a2a12c3a2a2447cd8279a0a[ALL] 02db81b6869ecc5adaee19ed95c08d25911de7f6a9ccc91d4070c010e782fd64bc",
"hex": "47304402206cd673c4fd5d3a22fb2601eb6d28d486ffb8493b2334b2205e603c89cd66da85022063b9d89926657fdc021a8e0bdc48b3d8416acea81a2a12c3a2a2447cd8279a0a012102db81b6869ecc5adaee19ed95c08d25911de7f6a9ccc91d4070c010e782fd64bc"
},
"sequence": 4294967294
}
],
"vout": [
{
"value": 101.00000000,
"n": 0,
"scriptPubKey": {
"nameOp": {
"op": "name_update",
"name": "labi",
"value": "{"0":{"wp":[97,487]}}"
},
"asm": "OP_NAME_UPDATE 1768055148 7b2230223a7b227770223a5b39372c3438375d7d7d OP_2DROP OP_DROP OP_DUP OP_HASH160 24aca122ba5885b2bc29521c64138259e21be99d OP_EQUALVERIFY OP_CHECKSIG",
"hex": "53046c616269157b2230223a7b227770223a5b39372c3438375d7d7d6d7576a91424aca122ba5885b2bc29521c64138259e21be99d88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"H9s3Wkfjfd6FBB8EKzH79LeNK7LUcbeAXm"
]
}
},
{
"value": 1.79000000,
"n": 1,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 a85870cc40c108332e28ecea5307dc72b79e5ecd OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a914a85870cc40c108332e28ecea5307dc72b79e5ecd88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"HMsFrXuGy9gCogXZtP86gPiauFxARZwMKn"
]
}
}
]
**Decoded first confirmed transaction that caused conflict
249dea937dc353154abec3f464b656e09a99711a1391b12189ee9cb44c693fe4
{
"txid": "249dea937dc353154abec3f464b656e09a99711a1391b12189ee9cb44c693fe4",
"hash": "249dea937dc353154abec3f464b656e09a99711a1391b12189ee9cb44c693fe4",
"size": 476,
"vsize": 476,
"version": 28928,
"locktime": 1557212,
"vin": [
{
"txid": "cf185b52b2e8dbbcd15e4af26d9272b515f4018fb7b94279c348b975b7363dfc",
"vout": 1,
"scriptSig": {
"asm": "3044022076f34907e4d2327e1bd904b6c71c46cbf813833ae6fbbd081baaad880deabf8f022026970415b26cd781a7d011bc75549e514f6f2ed7741c89e8eb6ceef6a534ee3a[ALL] 0301e6b8737c494655f357d0bb20a9197f1d655fd8d5227790c73def1bb57eeac5",
"hex": "473044022076f34907e4d2327e1bd904b6c71c46cbf813833ae6fbbd081baaad880deabf8f022026970415b26cd781a7d011bc75549e514f6f2ed7741c89e8eb6ceef6a534ee3a01210301e6b8737c494655f357d0bb20a9197f1d655fd8d5227790c73def1bb57eeac5"
},
"sequence": 4294967294
},
{
"txid": "f81c18f99e5c5b0a6e332f5d371ee7d5e5a5cfd3c28506281382fefcf85d6186",
"vout": 2,
"scriptSig": {
"asm": "3045022100df720d669b8029d1f0cc18ba1904c28b0fad315959bb92617f28314d91ff14bf0220243ff2dc217ed9c5a8f736e523e378ac6ded64e442a8ca58039b7dfc4f5ccbe0[ALL] 02db81b6869ecc5adaee19ed95c08d25911de7f6a9ccc91d4070c010e782fd64bc",
"hex": "483045022100df720d669b8029d1f0cc18ba1904c28b0fad315959bb92617f28314d91ff14bf0220243ff2dc217ed9c5a8f736e523e378ac6ded64e442a8ca58039b7dfc4f5ccbe0012102db81b6869ecc5adaee19ed95c08d25911de7f6a9ccc91d4070c010e782fd64bc"
},
"sequence": 4294967294
}
],
"vout": [
{
"value": 102.00000000,
"n": 0,
"scriptPubKey": {
"nameOp": {
"op": "name_update",
"name": "Cep",
"value": "{"0":{"wp":[429,187,429,188,431,190,431,192,430,191,430,194,431,194,432,193],"destruct":true}}"
},
"asm": "OP_NAME_UPDATE 7365955 7b2230223a7b227770223a5b3432392c3138372c3432392c3138382c3433312c3139302c3433312c3139322c3433302c3139312c3433302c3139342c3433312c3139342c3433322c3139335d2c226465737472756374223a747275657d7d OP_2DROP OP_DROP OP_DUP OP_HASH160 c82987edc8a616c86aec7720a743efc970599286 OP_EQUALVERIFY OP_CHECKSIG",
"hex": "53034365704c5e7b2230223a7b227770223a5b3432392c3138372c3432392c3138382c3433312c3139302c3433312c3139322c3433302c3139312c3433302c3139342c3433312c3139342c3433322c3139335d2c226465737472756374223a747275657d7d6d7576a914c82987edc8a616c86aec7720a743efc97059928688ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"HQmVHLGD3AKYbiV3Nu3cE5aRPQyAtMKnqK"
]
}
},
{
"value": 0.79000000,
"n": 1,
"scriptPubKey": {
"asm": "OP_DUP OP_HASH160 3e68df06302ee9a19e21a23e8a8191ba722225fd OP_EQUALVERIFY OP_CHECKSIG",
"hex": "76a9143e68df06302ee9a19e21a23e8a8191ba722225fd88ac",
"reqSigs": 1,
"type": "pubkeyhash",
"addresses": [
"HCD7upGFpVahXGqF7QWZZfZry4nRfHJk8P"
]
}
}
]
}
**Decoded second confirmed transaction that caused conflict
55bd74586016dea8027c8c0d51b569e7e5bbeb0d931ea6d104a15a22bf29c086
{
"txid": "55bd74586016dea8027c8c0d51b569e7e5bbeb0d931ea6d104a15a22bf29c086",
"hash": "55bd74586016dea8027c8c0d51b569e7e5bbeb0d931ea6d104a15a22bf29c086",
"size": 103,
"vsize": 103,
"version": 553216,
"locktime": 0,
"vin": [
{
"gametx": {
"player": "hof",
"op": "spawn_death"
},
"scriptSig": {
"asm": "6713192 OP_NAME_NEW",
"hex": "03686f6651"
},
"sequence": 4294967295
},
{
"gametx": {
"player": "labi",
"op": "spawn_death"
},
"scriptSig": {
"asm": "1768055148 OP_NAME_NEW",
"hex": "046c61626951"
},
"sequence": 4294967295
}
],
"vout": [
]
}
The text was updated successfully, but these errors were encountered: