Broadcast a signed transaction

Question

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.

Answer 1

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

Answer 2

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.