<p>You could broadcast a transaction that depends on a parent transaction that you don't broadcast until 2 hours later. This would ensure that the child transaction cannot make it into a block until the parent has been transmitted.</p>
<p>Technically, this satisfies your requirements. However, orphan transactions do not get stored into the mempool of bitcoin nodes, but instead are stored in a small (usually room for only 100) orphan cache. So there's a very high chance that it won't be known by the network 2 hours later when the parent is broadcast - i.e. the child will need to be broadcast again.</p>

CC BY-SA 4.0
2020-03-01T16:55:15.713Z
2021-08-23T13:32:43.000Z
2021-08-23T13:32:43.000Z
Rebroad
<p>You can achieve this with timelocks.</p>

<p>The bitcoin wiki says "A Timelock is a type of smart contract primitive that restricts the spending of some bitcoins until a specified future time or block height."</p>

<p><strong>EDIT</strong></p>

<p>Further, it reads:</p>

<p><strong>CheckLockTimeVerify</strong></p>

<p>In late 2015, the BIP65 soft fork[6] redefined the NOP2 opcode as the CheckLockTimeVerify (CLTV) opcode, allowing transaction outputs (rather than whole transactions) to be encumbered by a timelock. When the CLTV opcode is called, it will cause the script to fail unless the nLockTime on the transaction is equal to or greater than the time parameter provided to the CLTV opcode. Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block.</p>

<p>CLTV is currently used in CLTV-style payment channels.</p>

<p><strong>Relative locktime</strong></p>

<p>In mid-2016, the BIP68/112/113 soft fork gave consensus-enforced meaning to some values in the nSequence field[7] that is a part of every transaction input, creating a "relative locktime"[citation needed]. This allowed an input to specify the earliest time it can be added to a block based on how long ago the output being spent by that input was included in a block on the block chain.</p>

<p>CheckSequenceVerify
Also part of the BIP68/112/113 soft fork was the CheckSequenceVerify opcode[8], which provides for relative locktime the same feature CLTV provides for absolute locktime. When the CSV opcode is called, it will cause the script to fail unless the nSequence on the transaction indicates an equal or greater amount of relative locktime has passed than the parameter provided to the CSV opcode. Since an input may only be included in a valid block if its relative locktime is expired, this ensures the CSV-based timelock has expired before the transaction may be included in a valid block.</p>

<p>Hope this helps.</p>

CC BY-SA 4.0
2020-02-29T01:54:05.383Z
Timelocked transactions are not broadcastable until the timelock expires, so this is not a solution to OP's question.
Pieter Wuille
CC BY-SA 4.0
2020-03-01T16:28:12.193Z
I meant specifically CHECKSEQUENCEVERIFY.
ecavero
CC BY-SA 4.0
2020-03-01T16:57:15.260Z
Same. Those are still not broadcastsble until the relative locktime has passed.
Pieter Wuille
CC BY-SA 4.0
2020-02-28T19:55:03.603Z
2020-03-01T16:33:36.587Z
2020-03-01T16:33:36.587Z
ecavero
<p>I know that it's sounds ridiculous, but i need to create an unconfirmed bitcoin transaction that will be unconfirmed for 2+ hours.I came to a conclusion that i need to create a 0 fee transactions but can't find a solution to make it and broadcast. Another variant was to set the min. fee ( 1sat/byte ) , but sometimes it's got confirmed after 5-10 minutes.How can a achieve the desired result ?</p>

CC BY-SA 4.0
2020-02-03T21:37:37.433Z
By not broadcasting it ? :D
More seriously, what are you trying to achieve ?
Antoine Poinsot
<bitcoin-core><transaction-fees><electrum><unconfirmed-transactions><raw-transaction>
Creating a unconfirmed bitcoin transaction
Cristyan
# Creating a unconfirmed bitcoin transaction

(Asked by: username_0 on 2020-02-03)

I know that it's sounds ridiculous, but i need to create an unconfirmed bitcoin transaction that will be unconfirmed for 2+ hours.I came to a conclusion that i need to create a 0 fee transactions but can't find a solution to make it and broadcast. Another variant was to set the min. fee ( 1sat/byte ) , but sometimes it's got confirmed after 5-10 minutes.How can a achieve the desired result ?

**Tags:** bitcoin-core, transaction-fees, electrum, unconfirmed-transactions, raw-transaction

> **Comments:**
> **username_1**: By not broadcasting it ? :D More seriously, what are you trying to achieve ?  

---

## 2 answers

### Answer by username_2 on 2020-03-01. Score: 2

You could broadcast a transaction that depends on a parent transaction that you don't broadcast until 2 hours later. This would ensure that the child transaction cannot make it into a block until the parent has been transmitted.

Technically, this satisfies your requirements. However, orphan transactions do not get stored into the mempool of bitcoin nodes, but instead are stored in a small (usually room for only 100) orphan cache. So there's a very high chance that it won't be known by the network 2 hours later when the parent is broadcast - i.e. the child will need to be broadcast again.


---

### Answer by username_3 on 2020-02-28. Score: 0

You can achieve this with timelocks.

The bitcoin wiki says "A Timelock is a type of smart contract primitive that restricts the spending of some bitcoins until a specified future time or block height."

**EDIT**

Further, it reads:

**CheckLockTimeVerify**

In late 2015, the BIP65 soft fork[6] redefined the NOP2 opcode as the CheckLockTimeVerify (CLTV) opcode, allowing transaction outputs (rather than whole transactions) to be encumbered by a timelock. When the CLTV opcode is called, it will cause the script to fail unless the nLockTime on the transaction is equal to or greater than the time parameter provided to the CLTV opcode. Since a transaction may only be included in a valid block if its nLockTime is in the past, this ensures the CLTV-based timelock has expired before the transaction may be included in a valid block.

CLTV is currently used in CLTV-style payment channels.

**Relative locktime**

In mid-2016, the BIP68/112/113 soft fork gave consensus-enforced meaning to some values in the nSequence field[7] that is a part of every transaction input, creating a "relative locktime"[citation needed]. This allowed an input to specify the earliest time it can be added to a block based on how long ago the output being spent by that input was included in a block on the block chain.

CheckSequenceVerify
Also part of the BIP68/112/113 soft fork was the CheckSequenceVerify opcode[8], which provides for relative locktime the same feature CLTV provides for absolute locktime. When the CSV opcode is called, it will cause the script to fail unless the nSequence on the transaction indicates an equal or greater amount of relative locktime has passed than the parameter provided to the CSV opcode. Since an input may only be included in a valid block if its relative locktime is expired, this ensures the CSV-based timelock has expired before the transaction may be included in a valid block.

Hope this helps.

> **Comments:**
> **username_4**: Timelocked transactions are not broadcastable until the timelock expires, so this is not a solution to OP's question.  
> **username_3**: I meant specifically CHECKSEQUENCEVERIFY.  
> **username_4**: Same. Those are still not broadcastsble until the relative locktime has passed.  

---

