4

I sent money from 4 inputs to 2 outputs, one of which I don't control. The transaction's fee is too small (didn't change my settings and the transaction fees got a lot higher, recently) and will not confirm anytime soon.

I then created a new transaction spending 2 of the 4 inputs of the original transaction to 1 output. This transaction is obviously doubple-spending.

After trying to breadcast the second transaction via Electrum and with several online services, still not a single one broadcasted it. They all know it's a double-spend and won't broadcast double-spends.

Subsequently, I installed bitcoin-qt, hoping to be able to send the transaction directly to my peers.

I never used the bitcoin-qt console before, so I hope this is correct:

sendrawtransaction 010000000189

I cut the string off after 12 characters. The entire signed transaction is 382 hexadecimal digits long. Do I need to use quotes, some kind of brackets, a semicolon, something else?

The error message it returned is this:

Missing inputs (code -25)

I don't know what this error message means exactly but in case it means that the inputs were not found in the UTXO set generated from the part of the blockchain that was already downloaded:

bitcoin-qt doesn't know my inputs as they are only between a few months and a few weeks old but it shouldn't have to to send a signed transaction.

It doesn't know my private keys either, but again, it shouldn't have to.

Can I force it to do so even if it can't check whether the inputs exist? The reason is that I'm on a super slow internet connection and downloading the blockchain would take several days, even if nothing else went over the connection during that time.

Improve this question
4
  • I think the best you can do is, unfortunately, wait. Your transaction with low fees will not likely be included into a block, but it is in the mempool of the Bitcoin nodes, since, according to what you said, several online services do not forward your doble-spending transaction, that is, there is a conflict with the new one you want to create a then old one they already have. Eventually the old transaction will be deleted from them mempool, and you will be able to spend then output again.
    – sr-gi
    Feb 21 '17 at 16:19
  • @sr_gi Unfortunately, I think I will still have to send a conflicting transaction via a client as online services seem to have really big mempools and keep transactions for a long time. I don't know how big the mempools of Electrum's servers are. Do you know of any different wallet which will let me broadcast raw transactions? (Possibly in the future.)
    – UTF-8
    Feb 21 '17 at 16:48
  • Not really, I've normally used bitcoind or online API like blockr's or blockexplorer's. However, even though Electrum may keep transactions in their nodes' mempool for a longer time than others (I do not know about this), this do not mean that you could not use other services to broadcast the "double-spend transaction". As long as other nodes start relaying the new transaction (once they purge the old one from their mempool), it will end in the blockchain.
    – sr-gi
    Feb 21 '17 at 16:56
  • I came across a new solution that may be useful. Check it out!
    – sr-gi
    Feb 22 '17 at 11:40
3

It doesn't seems to be a better solution than waiting. The original transaction (the 4 inputs 2 outputs one) has been relayed by the Electrum node that received it and spread over the network, therefore, it's in the mempool of the network nodes. Every transaction that tries to spend the same UTXO referred by the first transaction will be marked as double-spending until the first transaction is pruned from the mempool. Hence, waiting is unfortunately the only solution that comes to my mind.

Edit: Answering another question I came across a thing that could also be useful for you. You can use a CPFP approach. To do so, try to spend from the transaction that is pending to be confirmed with a new one with high fee. This new transaction will be like a candy for miners, and in order to include it in a block, they must include the previous also.

Edit2: Regarding the error message provided, there is a problem in how the transaction that the author wants to send (T1 from now on) has been build. The scriptSig of the transaction is not properly set.

The serialised T1 is:

01000000018964907116f6245417b9d9aea1d226e46486c5d485d6b947c95c794e032df612010000001976a9140043be27e16b93c275413e9b4411f08f2cd8bef088acffffffff0120082f08000000001976a9140b01599fd09ef602d71827601871e5a1081459f688ac00000000

Is we decode T1 we will get something like:

version: 01000000
number of inputs: 01 (1)
input 0
     previous txid (little endian): 8964907116f6245417b9d9aea1d226e46486c5d485d6b947c95c794e032df612 (12f62d034e795cc947b9d685d4c58664e426d2a1aed9b9175424f61671906489)
     previous tx output (little endian): 01000000 (1)
     input script (scriptSig) length: 19 (25)
     input script (scriptSig): 76a9140043be27e16b93c275413e9b4411f08f2cd8bef088ac
     nSequence: ffffffff
number of outputs: 01 (1)
output 0
     Satoshis to be spent (little endian): 20082f0800000000 (137300000)
     output script (scriptPubKey) length: 19 (25)
     output script (scriptPubKey): 76a9140b01599fd09ef602d71827601871e5a1081459f688ac
nLockTime: 00000000

At this point, we can notice that the scriptSig is incorrect. Analysing it carefully, we can notice that it has the structure of a P2PKH scriptPubKey instead of the corresponding signature that should complement the scriptPubKey of the previous transaction (T0 from now on):

76a9140043be27e16b93c275413e9b4411f08f2cd8bef088ac =
OP_DUP OP_HASH160 0043be27e16b93c275413e9b4411f08f2cd8bef0 OP_EQUALVERIFY OP_CHECKSIG

If we want to be definitely sure about this, we can check the scriptPubKey of the UTXO from T0 we are trying to spend, and analyse both scripts.

The UTXO from T0 we are interested in can be identified by (id:index):

12f62d034e795cc947b9d685d4c58664e426d2a1aed9b9175424f61671906489:1

If we look for the specific scriptPubKey that contains that UTXO, we will find:

OP_DUP OP_HASH160 0043be27e16b93c275413e9b4411f08f2cd8bef0 OP_EQUALVERIFY OP_CHECKSIG

That curiously matches with the scriptSig that we have found in T1.

Conclusion

T1 scriptSig (input 0) and T0 scriptPubKey (output 1) shared the sames script. T1 scriptSig must provide the signature required in T0 scriptPubKey in order to pass the validation:

scriptSig:  [signature]    
sciptPubKey: OP_DUP OP_HASH160 0043be27e16b93c275413e9b4411f08f2cd8bef0 OP_EQUALVERIFY OP_CHECKSIG
Improve this answer
12
  • That approach, unfortunately, won't work. I thought about doing CPFP, too, but the one output I control is too small to make a difference.
    – UTF-8
    Feb 22 '17 at 12:29
  • Can't you use it together with another UTXO you own, not necessarily associate with the same address, to build a transaction in which include a fee that does the trick?
    – sr-gi
    Feb 22 '17 at 12:35
  • Ah, thanks! I have no idea why I didn't think of this. Do you know what bitcion-qt's message means, though? Knowing this could be useful for the future when I want to send raw transactions.
    – UTF-8
    Feb 22 '17 at 12:57
  • Not exactly, but it seems to be, indeed, that an input is missing. github.com/bitcoin/bitcoin/blob/… However, the error code corresponds to a generic error when submitting a block/transaction. github.com/bitcoin/bitcoin/blob/…
    – sr-gi
    Feb 22 '17 at 13:42
  • But in that case, the input actually doesn't exist. In my case, the inputs do exist. They only aren't downloaded. At this point, the coins' existence is checked. view.AccessCoins should point to (I haven't checked in an IDE, just read through it on GitHub) this method where
    – UTF-8
    Feb 22 '17 at 17:33
0

Short answer; you will have to wait. It will end up resolving, but may take a day or more. There's a longer answer I could provide; but it won't change the fact that waiting is all you can do.

Improve this answer
2
  • The transaction's fee is 0.15 mBTC (around 17 ¢, right now), whereas transactions which go through currently have at least 3 times that as a fee. It won't confirm for quite some time and possibly will have been removed from many mempools way before it goes through. Is there a way to make bitcoin-qt send the raw transaction I prepared? It could propagate after enough nodes removed the first transaction from their mempools. Is there an alternative Bitcoin software which can do this? (Send it directly via my IP, not via an external service.)
    – UTF-8
    Feb 21 '17 at 19:55
  • You can do nothing but wait. If the transaction has already been seen by (N) nodes, those nodes will need to eventually timeout and drop the transaction, which is when it will be returned to you. Rebroadcasting it, or having more nodes "see" it will not increase it's chance of a block accepting it; because the node which finds a block already knows about it; it's out there; been broadcast (and based off of the fee the block finding node will include or not include it based off their own settings of fees they accept). That said; your transaction is in the mempool. All you can do is wait.
    – McFlySoHigh
    Feb 22 '17 at 16:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.