Can one create such a transaction that is valid?

[CryptoGPU]

Can one create such a transaction that is valid:

Transaction with 2 inputs and 1 output.
First input uses an UTXO that comes from an earlier block and is unspent and valid.
Second input spends the output of this transaction.

Curious if this is possible.

Thanks for your answers.

[1714263451]

1714263451

[Charles-Tim]

First input uses an UTXO that comes from an earlier block and is unspent and valid.

If the UTXO is valid, it can be spent in a transaction.

Second input spends the output of this transaction.

The transaction inputs are the UTXOs that are spent that make up the transaction outputs. Without the inputs, there will not be anything like the outputs. That means transaction input can not spend any of the output of its transaction.

[Zaguru12]

You question is not that clear, but I will answer base on my understanding

Yes the input can definitely be spent and UTXOs are definitely in earlier blocks to been used as an input for a new transaction because they are confirmed earlier. Then the second input might be for new transaction where you use the output of the first transaction as the input through CPFP method.

But if what you mean is having the second input and the first in one transaction then I don’t think it will work because this is like spending from an un initiated transaction.

You can redress your question we’ll go get the right answer

[CryptoGPU]

But if what you mean is having the second input and the first in one transaction then I don’t think it will work because this is like spending from an un initiated transaction.
You can redress your question we’ll go get the right answer

Yes, one transaction.

Without the inputs, there will not be anything like the outputs.

I asked, because it is possible to spend the output of a transaction with another transaction on the same block, although the output isn't on the blockchain, both transactions will go through in one block.

[Charles-Tim]

I asked, because it is possible to spent the output of a transaction with another transaction on the same block, although the output isn't on the blockchain, both transactions will go through in one block.

The way you can refer to this that people will easily understand is child-pay-for-parent (CPFP). If the transaction has change address UTXO which is the second input that you were referring to.

Then, yes. The second input can spend the output of the transaction which is the parent unconfirmed change address UTXO. But the change address UTXO should be regarded as an output that is sent back to the change address of the sender's wallet.

[CryptoGPU]

.

Ok, that means the transaction could have 2 inputs and 2 outputs and one output is a CPFP unconfirmed UTXO that will be spent by input 2 (back to sender's wallet), so it would work?

[Charles-Tim]

Ok, that means the transaction could have 2 inputs and 2 outputs and one output is a CPFP unconfirmed UTXO that will be spent by input 2, so it would work?

Yes. But it is worth mentioning that the first transaction transaction can even has 1 input and if the transaction has a change, it will have 2 outputs which are, first the coins to the destination address the sender sends the coin to and the second is the remaining coins sent to change address as change.

[nc50lc]

Ok, that means the transaction could have 2 inputs and 2 outputs and one output is a CPFP unconfirmed UTXO that will be spent by input 2 (back to sender's wallet), so it would work?

That's not possible.
A transaction cannot spend its own output.

I asked, because it is possible to spend the output of a transaction with another transaction on the same block, although the output isn't on the blockchain, both transactions will go through in one block.

Even though unconfirmed transactions aren't yet included in the blockchain, nodes still enforce transaction relay rules before including them to their own mempool.
Spending an unconfirmed transaction's output with a new separate transaction isn't prohibited, that's why it's possible.

But spending its own output in the same transaction isn't going to be easy to implement.
One reason is: how it is supposed to refer an output point (txid:vout) while the txid should be the hash of the signed raw transaction (w/o witness) while requiring it to include the output point which has the txid of the same transaction as an input?
It may require a different transaction structure to implement.

[o_e_l_e_o]

I asked, because it is possible to spend the output of a transaction with another transaction on the same block, although the output isn't on the blockchain, both transactions will go through in one block.

This is only possible if the parent transaction creating the output comes earlier in the block than the child transaction which is spending that output.

Nodes will verify the transactions in the order they appear in the block, and update their UTXO set in that order as well. The child transaction will refer to the output being spent by the TXID of the parent transaction. If that parent transaction does not come before the child transaction in the block, then the nodes will not yet have the output in their UTXO set and so the child transaction will be invalid. (This actually happened very recently with a mining pool messing up the order of transactions in a block, and the block therefore being rejected as invalid.)

So by the same logic that a parent transaction cannot come later in a block than the child transaction, the same transaction cannot spend a UTXO it creates. When nodes come to verify that transaction they will look for the output in their UTXO set, and since it does not yet exist the transaction will be invalid.

[CryptoGPU]

Thanks for your answers.

Maybe you know about Ordinals/Inscriptions on the Bitcoin blockchain and its transaction structure to create an Inscription. The initiator Casey introduced Inscriptions so, that you need TWO transactions to create 1 Inscription.
1. commit transaction
2. reveal transaction

He explains it so:
"Since taproot script spends can only be made from existing taproot outputs, inscriptions are made using a two-phase commit/reveal procedure. First, in the commit transaction, a taproot output committing to a script containing the inscription content is created. Second, in the reveal transaction, the output created by the commit transaction is spent, revealing the inscription content on-chain."

Wouldn't it be possible to have ONE transaction to create an Inscription?

[pooya87]

Wouldn't it be possible to have ONE transaction to create an Inscription?

What the attack known as Ordinals calls "inscription" is simply an arbitrary data injected into the bitcoin blockchain by exploiting the protocol. Now the answer to your question is clearer, you can inject arbitrary data into the blockchain in one transaction very easily. The correct way is using an OP_RETURN output to do so.

[nc50lc]

He explains it so:
"Since taproot script spends can only be made from existing taproot outputs, inscriptions are made using a two-phase commit/reveal procedure. First, in the commit transaction, a taproot output committing to a script containing the inscription content is created. Second, in the reveal transaction, the output created by the commit transaction is spent, revealing the inscription content on-chain."

Even for non-ordinals, that "two-phase" procedure is basically what other bitcoin transaction do.
First, the output doesn't reveal anything in the output script aside from a hash of the the 'redeem script', public key, etc. depending on the script type.
Then, when used as input, the required data is revealed.

Wouldn't it be possible to have ONE transaction to create an Inscription?

It still falls under the structure of a valid transaction.

With using the current structure, under "inputs" field, we'll need to get the TXID of the UTXO that we're trying to spend; in your case, the same transaction that you're creating.
The transaction should be finalized (fully signed, ready to be broadcasted) in order to compute a hash to generate a valid txid and we can't do that while the data of the input still needing that txid.