6

Is it possible to add an input to a transaction that is in the mempool?

For example, if someone is paying 1 BTC to their friend, I can get the raw hex data of this transaction from the mempool before it is mined.

I can then sign an unspent transaction (Let's say 3 BTC) with my own private key, list it as an input, and get the raw hex data for this. Then, I can add a 3 BTC output to someone else's address (who I want to pay), and re-broadcast this new transaction to the network.

What is stopping this from happening?

Improve this question

4 Answers 4

Reset to default
5
+50

Short answer: no, this is impossible.

Longer answer: some transactions allow changing the inputs used (ANYONECANPAY inputs). It is also possible to have inputs which do not sign the outputs being created (SIGHASH_NONE). However, a transaction where all inputs are of this type, are worthless, as anyone could change the outputs to credit themselves instead.

Typically, when normal SIGHaSH_ALL signatures are used, pretty much everything of a transaction is signed (which input coins are used (and in which order), what output scripts are created, what value to assign to them, ... Everything except the signatures themselves really (which is what causes involuntary malleability).

If an input signature is marked ANYONECANPAY, it does not sign the other input coins being used. This means you can create a transaction meaning "i want x and y to be paid, but i don't care who provides the funds to do so". If all signatures in a transactioon are ANYONECANPAY, you could add extra inputs (or remove existing inputs. Just increasing the input funds would just burn them as fee, though.

On the other side, there is SIGHASH_NONE, which makes a signature not sign the transaction's outputs. This may seem to allow what you want to, but in case every signature is SIGHASH_NONE, the treansaction is completely unsafe, as anyone could replace where the outputs go.

So, even if a combination of those would in theory allow what you suggest, it is not true for typical tramsactions, amd would in fact be completely unsafe.

Improve this answer
3
  • Thanks. I have looked at the code for over an hour and I still don't see where the outputs are signed, though. I am specifically looking here: github.com/bitcoin/bitcoin/blob/master/src/… ... it seems only inputs are signed? Can you point to a line of code that makes it clear that transaction outputs are signed as well?
    – bvpx
    Commented Mar 22, 2014 at 10:30
  • 1
    Also, I can "just believe you", but I don't see anything in the code that prevents the type of behavior I am asking about. Specifically, what is preventing someone from adding an input to an un-mined SIGHASH_ALL transaction? Saying "everything is signed" doesn't fully answer my question, I feel like I am missing something important. Are all inputs signed with every private key that is listed in the transaction? From what I can tell, each input is signed individually and the data of that signature is stored independently from the other input signatures.
    – bvpx
    Commented Mar 22, 2014 at 10:35
  • 3
    Every input is contains a signature, using the key needed by the script of the output being spent by that input. However the data being signed is (a modified version of) the entire transaction. Adding an extra input to a transaction would invalidate any SIGHASH_ALL inputs to it, as the data being signed changes.
    – Pieter Wuille
    Commented Mar 23, 2014 at 1:18
1

It is not possible to add an extra input (or output) to someone else's transactions without getting them to sign the new transaction because their signature is only valid for the given underlying inputs and outputs.

A possible source of confusion is that other aspects of a transaction are indeed malleable (they can be altered until they are finalized by incorporation into the blockchain in the mining process). For example, there is a trivial transformation of forming a new valid signature from an existing valid signature that is essentially taking the negative of it, and leading zeroes can be prepended as well. In a sense this is a legacy problem because signatures used to, before Bitcoin, be seen as having a value in confirming the authenticity of other data, not in being unique themselves, such that in the unexpected case of seeing these non-standard formats for signatures, defaulting to accepting them was a reasonable choice.

No such alteration changes the underlying transfer of Bitcoin, they only change the hash (transcation id or txid) of the existing transaction. This means that such alteration could confuse the parties involved, as the transaction gets confirmed under an unexpected txid, but they do not affect how many bitcoin are transferred from what inputs to what outputs.

Improve this answer
0

You can't, it would create a completely different transaction and the other would get invalidated as soon as one makes it to a miner and into a block.

Improve this answer
5
  • I'm confused, are you saying this isn't possible, or are you saying that it is possible and it would simply make the first transaction invalid?
    – bvpx
    Commented Mar 12, 2014 at 20:23
  • My bad, the second paragraph was confusing. I'm saying the second transaction will be invalid because of conflicting inputs.
    – John T
    Commented Mar 12, 2014 at 20:48
  • I was under the impression that transaction malleability was possible due to there being no order of transactions enforced (before a block is mined with that transaction in it). Is it possible for the second larger transaction to be put in a block?
    – bvpx
    Commented Mar 12, 2014 at 21:40
  • Once a transaction is in a block or even in a miner's memory pool, all conflicting transactions are invalid. There are no input duplicates ever in the blockchain. Transaction malleability creates two TXIDs that point to the same transaction, but only one can be valid and placed in a block. Accepting both as valid is where exchanges lose money.
    – John T
    Commented Mar 12, 2014 at 23:05
  • My question specifically references transactions that are not mined yet. The question is whether or not it is possible to edit the raw transaction to add inputs and outputs before the transaction is mined because each input is signed individually. I am not asking about duplicate inputs, I'm asking whether or not it's possible to add inputs and outputs to a transaction that hasn't been mined yet, with the hopes of re-broadcasting it to pools to have it mined before the "host" transaction is mined. I can't find anything in the protocol that would technically stop this from happening.
    – bvpx
    Commented Mar 14, 2014 at 19:33
0

These things cannot change:

Usually* a bitcoin transaction includes a signature to confirm the following things:

  1. Input
  2. Output

An input or output specifies both an address and an amount. If either of these things change, then a new signature will be needed, which can only be created by someone who has the private key. Changing the input or the output will invalidate the signature. Only the owner of the private key can make such a change, being the only one who can create the new signature. Even then, this would create an entirely new transaction which could not be mistaken for the original.

The thing which can be changed prior to the transaction being included in the blockchain is the transaction id. Changing this can cause confusion for anyone who accepts unconfirmed transactions, but it cannot change the input or output - it is just a label. For people who only accept confirmed transactions, the transaction will already be in the blockchain, where nothing can be altered so there is no opportunity for confusion.

In conclusion:

  • Your transaction which hasn't been included in the blockchain yet is safe from having its input or output changed. Neither addresses nor amounts can be changed or added to.
  • Once your transaction is included in the blockchain** it is safe from having anything changed, so you can safely refer to it by its transaction id without any potential for confusion.

Extra info

I was aiming for a simple explanation so I have not included detail of transactions with multiple inputs with different private keys, but the same applies. No third party can make alterations other than the transaction id, which does not affect what bitcoin amount is transferred or where it is transferred from and to.

The explanation above applies to standard transactions. Producing a transaction to which these protections do not apply would require either specialist software or an in depth understanding. For further detail on transactions see the following:

*While it is possible to deliberately create a transaction which does not specify inputs, or even one which does not specify outputs, I am assuming that the question concerns the usual process of creating a transaction from specified input(s) to specified output(s).

**By "included in the blockchain" I mean included with however many confirmations you consider sufficient for your purposes. If a transaction has only one confirmation then it is still possible that the block it has been included in will become orphaned later. With each additional confirmation the risk of this happening decreases considerably.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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