Broadcast a signed transaction

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.

UTF-8

Posted 2017-02-21T15:49:22.713

Reputation: 2 941

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 – 2017-02-21T16:19:13.947

@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 – 2017-02-21T16:48:11.357

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 – 2017-02-21T16:56:11.993

I came across a new solution that may be useful. Check it out! – sr-gi – 2017-02-22T11:40:56.690

Answers

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

sr-gi

Posted 2017-02-21T15:49:22.713

Reputation: 2 382

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 – 2017-02-22T12:29:27.480

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 – 2017-02-22T12:35:33.187

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 – 2017-02-22T12:57:04.693

Not exactly, but it seems to be, indeed, that an input is missing.

https://github.com/bitcoin/bitcoin/blob/4d8558a2871ec70b9d09028c49fa39e4911435f5/qa/rpc-tests/rawtransactions.py#L67

However, the error code corresponds to a generic error when submitting a block/transaction.

https://github.com/bitcoin/bitcoin/blob/62f2d769e45043c1f262ed45babb70fe237ad2bb/src/rpc/protocol.h#L49

– sr-gi – 2017-02-22T13:42:16.443

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 – 2017-02-22T17:33:52.567

FetchCoins is called which in turn calls GetCoins. I don't see how that method gets the coins, though. But if it does, it looks like you can send raw transactions even if you yourself haven't downloaded the blockchain to the point where the coins are introduced. – UTF-8 – 2017-02-22T17:36:38.357

It is strange though, do yo mind providing the full serialized tx? That way I would try to check it field by field. – sr-gi – 2017-02-22T17:58:48.140

It's this: http://pastebin.com/Qef0YU2k

– UTF-8 – 2017-02-22T18:15:21.140

Alright, now I see. The input script of the transaction (scriptSig) is not correct. How have you built the transaction? I leave you why its wrong editing the answer, have no space here. – sr-gi – 2017-02-23T09:19:46.353

How did you build the transaction by the way, I'm quite curious about how that scriptSig ended up being there. – sr-gi – 2017-02-23T22:28:46.737

I used https://coinb.in to create the transaction. I entered the address the money is stuck in to identify the UTXO. It then looked for it and found it.

– UTF-8 – 2017-02-24T02:12:56.770

Ok, I see. Once you created the transaction, did you signed it using the signing function from the coinb.in web, if not, that could be the reason why the sigScript was containing incorrect data. Anyway, looks like the transaction finally got confirmed. Maybe we should close this. – sr-gi – 2017-02-24T09:17:14.510

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.

McFlySoHigh

Posted 2017-02-21T15:49:22.713

Reputation: 157

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 – 2017-02-21T19:55:01.153

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 – 2017-02-22T16:08:38.813