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

Conflicted transactions (reopen) #7

Open
MithrilMan opened this issue Jan 11, 2017 · 9 comments
Open

Conflicted transactions (reopen) #7

MithrilMan opened this issue Jan 11, 2017 · 9 comments

Comments

@MithrilMan
Copy link

MithrilMan commented Jan 11, 2017

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": [
]
}

@domob1812
Copy link
Owner

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.)

@MithrilMan
Copy link
Author

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

@domob1812
Copy link
Owner

Closing, feel free to reopen if you find more issues here not matching the explanation.

@MithrilMan
Copy link
Author

i have a new stuck transaction (conflicted) between two different hunters, here they are

this one died:


{
"amount": 0.00000000,
"fee": -0.01000000,
"confirmations": -13,
"trusted": false,
"txid": "cc5daec9524dede50a54809cfe11f407387907fa47f9dee2e0bfd73a63e58c81",
"walletconflicts": [
"ee9c84d7929be5b38cebf8be92d94af8a76e5dd0189062183a6cc328213a0f76",
"683fe953cbf80af44f717761e80d5e40216c4250ee67ddf20faf3b67d491137f"
],
"time": 1484860836,
"timereceived": 1484860836,
"bip125-replaceable": "unknown",
"details": [
{
"account": "",
"address": "HUEexcuzTiv7j3NRZKGbNTu7WS9PW72xVf",
"name": "update: fi",
"category": "send",
"amount": 0.00000000,
"vout": 0,
"fee": -0.01000000,
"abandoned": false
}
],
"hex": "0071000003dfabcae45cd8363b64a06e1dd898b49c6b5d50f240204eb2782a8a85edca4971010000006a47304402203f965f6c952c6221442cdc73cd5e77dfa0148b56b05123eb3e45a2c6eae92f64022017847644cc39e4f9ca54a7145709cc80af954ea2902ec757bb1c18a3567b737d012103ad7765f18248d586b21b891fc5dedc97c651bb944e2f5a0cfcfdd88272289bdcfeffffff0eded4da3f1ee0ecc32ca61c8b31ba180cced5d11eec4efd410fb8fbfb0ce6fb000000006b48304502210087ba3313991d75298f37196ef2e39ceca6dc7bdb7f805b0f6a7debebb37af91102201463e3b0271f41a423b157c70d2c1504d60317a21c1dfdcb28e780de884182f6012103318edb0a813b63bcf86df6d7be1aa8693c067c0aebce6057a097bcfd369f0c0afeffffffe28a477819a69b3c664e07be4fd66b45901da0aeed4eba9959570a81c7f58e09000000006b483045022100eac0f862a6c3cf2d5ca24dfe1d248144b4a87450e218333850816694150b515602201ce627ec934dd47c582603ea4e0fd4f43be4d6ae9f32ceee10042e67ddcf2b83012103fb5ec7fe5351ffd2edd1818e33b5e1e0b5b08b4ad79dba04befc206aa421837bfeffffff020068e36b020000003653026669167b2230223a7b227770223a5b3134342c3238335d7d7d6d7576a914ee3537b13afb30e4664b54097fde5afce6110b9288ace4761800000000001976a9141a710959cdd07ca350284632e8d7019a9b5579b188ac00f01700"
}

and went in conflict with this hunter, that's now stuck since 20 blocks


{
"amount": 0.00000000,
"fee": -0.01000000,
"confirmations": 0,
"trusted": true,
"txid": "683fe953cbf80af44f717761e80d5e40216c4250ee67ddf20faf3b67d491137f",
"walletconflicts": [
"cc5daec9524dede50a54809cfe11f407387907fa47f9dee2e0bfd73a63e58c81"
],
"time": 1484861104,
"timereceived": 1484861104,
"bip125-replaceable": "no",
"details": [
{
"account": "",
"address": "HJ5tHRCoPnjy2aBn2tVobfb4TBxRG9wch2",
"name": "update: me",
"category": "send",
"amount": 0.00000000,
"vout": 0,
"fee": -0.01000000,
"abandoned": false
}
],
"hex": "00710000020eded4da3f1ee0ecc32ca61c8b31ba180cced5d11eec4efd410fb8fbfb0ce6fb000000006a47304402201f6dd7a4e26cc36faa76c34a811b7fa4a3215a28567bc0ae87f9515908f2c25a0220048d1b9b916fd0834933edb34cf54e321c8d8d1628d93f16eb139df9c75cf846012103318edb0a813b63bcf86df6d7be1aa8693c067c0aebce6057a097bcfd369f0c0afeffffffb058ebd4bdcc9e2cd2f9f516cb5e3dd7e82fcfd40cf8ab3b7b8e04f50fa0e3eb010000006b4830450221008e4041f71f0bd84b8b76b5cc0256b941469d9aaebf413a7856e5a07fde6be6c3022037bfa5e17b4aa32749477aee8d985734a620e66bb22d78bd8856b352916c3237012102a563c52958864164e873bc613f391df12baa8f67c78444540a80751f9efd7026feffffff0200c5015a020000003e53026d651e7b2230223a7b227770223a5b3335392c3231392c3336342c3232345d7d7d6d7576a9147edb56a51f69ce771fc25b59bcacb545a3dba74688ac04390e00000000001976a914a4124e31d1b9e75283f0d0f9159ad149f567544e88ac05f01700"
}

what's the cause? how can i "unlock" the stuck hunter (that's alive but can't move?)

@MithrilMan
Copy link
Author

this is the other conflicting tx, (when "fi" have been killed)

{
"amount": 0.00000000,
"confirmations": 17,
"blockhash": "f87b35c63fcd0437ab2f81c2b06f3193cd97829f5957b15e94612066269fd4c5",
"blockindex": 12,
"blocktime": 1484861089,
"txid": "ee9c84d7929be5b38cebf8be92d94af8a76e5dd0189062183a6cc328213a0f76",
"walletconflicts": [
"cc5daec9524dede50a54809cfe11f407387907fa47f9dee2e0bfd73a63e58c81"
],
"time": 1484861089,
"timereceived": 1484861101,
"bip125-replaceable": "no",
"details": [
{
"account": "",
"name": "killed: fi",
"category": "killed",
"amount": 0.00000000,
"vout": 0,
"fee": 0.00000000,
"abandoned": false
}
],
"hex": "0071080001e28a477819a69b3c664e07be4fd66b45901da0aeed4eba9959570a81c7f58e09000000000a02666951056a61676172ffffffff0000000000"
}

@MithrilMan
Copy link
Author

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)

@MithrilMan MithrilMan changed the title Conflicted transactions Conflicted transactions (reopen) Jan 19, 2017
@MithrilMan
Copy link
Author

and this is another stuck transaction, but without any evidence of conflicted transaction

{
"amount": 0.00000000,
"fee": -0.01000000,
"confirmations": 0,
"trusted": true,
"txid": "7149caed858a2a78b24e2040f2505d6b9cb498d81d6ea0643b36d85ce4caabdf",
"walletconflicts": [
],
"time": 1484860737,
"timereceived": 1484860737,
"bip125-replaceable": "no",
"details": [
{
"account": "",
"address": "HTrzcPfEGNDuvCL5i3jKYaoXMyS79LjFnE",
"name": "update: a",
"category": "send",
"amount": 0.00000000,
"vout": 0,
"fee": -0.01000000,
"abandoned": false
}
],
"hex": "00710000028468c59dc2def58834e2ee3bf059cb142c47798cde1e36265ca2009d34c217ef000000006b483045022100fcd37719b4c09fedd46b10ffb24d870fb1ef4aff79a854adce2058971e9b0ee8022022c1389fb982e80a1dd6e8971833bebd899796764aaf690822baf308e09d51180121037cecd352945ab8d0436a8033d5652ef643b880c42f0792c3a55255f5cc6d66b3feffffff1b36b2c6f9610b2492076cfa2e3d1e59b5011e48b631548b86e108d00463b3ee000000006b483045022100d58d45f04a4fc80991304219047c6e163745c898ee8aeedf6a4e7a56576681f9022002664fb5222d2fa7083d5c4764b05f1d803c263befa2422018e08a62da7870df0121037431ee5f8c70a4f05db4e2f8876500d048760059cb5b2a338f545e131652f28afeffffff020087ed65020000003d5301611e7b2230223a7b227770223a5b3339372c3332312c3430302c3331375d7d7d6d7576a914ea1c786ce09bae77bee68a69fda0d71a3288bded88ace03d0a00000000001976a914c66df9c4cd9ba09f5baabe586175fd15cc01f0de88acfeef1700"
}

even restarting the client (wiping memory pool) didn't sorted any effect...
P.S.
not on a new wallet

@MithrilMan
Copy link
Author

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

@domob1812
Copy link
Owner

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 fbe60cfbfbb80f41fd4eec1ed1d5ce0c18ba318b1ca62cc3ece01e3fdad4de0e and ebe3a00ff5048e7b3babf80cd4cf2fe8d73d5ecb16f5f9d22c9eccbdd4eb58b0, you can check that with decoderawtransaction yourself.) That's good, as it would be a bug otherwise (since all tx depending on the conflicted tx should be marked conflicted as well). Possibly it would have gone unstuck by itself in this case.

@domob1812 domob1812 reopened this Jan 20, 2017
domob1812 pushed a commit that referenced this issue Aug 8, 2018
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants