Upper bound on transaction confirmation time

Today I saw a case where a transaction had a very low fee, so it got stuck in the mempool for days. The original wallet refused to allow a new transaction to be created with the same input, and in a case of mempool getting empty again, someone could rebroadcast that transaction and it would be accepted again.

So, the question: with current Script language, is it possible to create a transaction that becomes invalid if not included in a block before a certain time (or before a certain block height)? If so, how many bytes it would take up?

Such a transaction would be broadcast by common nodes, or they expect a certain specific signature format?

script

lvella

Posted 2017-09-21T20:23:23.773

Reputation: 246

"that becomes invalid if not included in a block before a certain time (or before a certain block height)?" This is impossible. – MCCCS – 2017-09-22T10:52:49.580

Answers

So, the question: with current Script language, is it possible to create a transaction that becomes invalid if not included in a block before a certain time (or before a certain block height)?

No, by design this is not possible.

The problem is that such a output would be very hard to assess the value of, when the timeout is close to being reached. Is the transaction going to be included, or become invalid? Even after it's confirmed, there are chances of it being reorganized out, and becoming invalid.

So by design no script features exist which depend on the context. A transaction is valid, or invalid. To deal with timing transactions can specify an nLockTime field which specifies the earliest possible time or height the transaction can be included in the chain at. The script language can introspect the nLockTime value, but not the actual time.

Pieter Wuille

Posted 2017-09-21T20:23:23.773

Reputation: 54 032

-1

with current Script language, is it possible to create a transaction that becomes invalid if not included in a block before a certain time (or before a certain block height)?

well, maybe not directly with the standard way of scripting transactions. Bitcoin has two functions for adding delay to a tx. Locktime/Sequence would not be working, cause it allows to define, by when a tx can go into the blockchain. If delay is not reached, it will not be mined, and stay in mempool. So it is the opposite of your requirement. But:

CSV (BIP112) or CLTV (BIP68): both allow to define a delay, before the next steps can be executed. One of the step could also be "OP_RETURN" or whatever leaves a "false" on the stack. This would terminate the script execution immediately, and mark the tx invalid.

If so, how many bytes it would take up?

This is maybe an additional 10-20 bytes for the IF/ELSE/ENDIF and the CSV or CLTV codes. But you would probably need a another tx. One as a "funding transaction", and this logic with the spending tx. So it would end up with a "bloat" of the blockchain.

Such a transaction would be broadcast by common nodes, or they expect a certain specific signature format?

This gets a bit tricky: these tx would need to be crafted annually, and they are defined as non-standard (which doesn't mean invalid though. But you have to find ways to bring it to a miner/into the network).

pebwindkraft

Posted 2017-09-21T20:23:23.773

Reputation: 4 568

I downvoted; this is wrong. CSV and CLTV do not delay steps in a program. They are time independent, and simply check whether the transaction has an acceptable locktime/sequence. There is intentionally no way these can be used to make a transaction fail after a certain point in time in order to not hurt fungibility (coins that are about to expire and aren't confirmed would be worth less than others). – Pieter Wuille – 2018-03-31T15:41:31.140

ACK. "Delay" was not precise enough, and the "tx invalid" was linked to the OP_Return, not CSV/CLTV (see also a previous explanation/reply here: https://bitcoin.stackexchange.com/questions/49303/op-return-marks-transaction-or-output-as-invalid). In the aftermath: the CSV/CLTV part doesn't even answer OPs question for a logic, that tx is invalidated before it gets in a block - with CSV/CLTV it would be already in a block. thx.

– pebwindkraft – 2018-03-31T22:28:55.313