Topic: Confirm TX at given block height (Read 296 times)
You can use OP_CHECKLOCKTIMEVERIFY to get a transaction into the blockchain now (and confirmed), but unspendable until a certain block in the future. The payment will not be reversible after it is confirmed, and the money becomes unusable until the block in the future, when only the recipient is allowed to spend it. Coinbin has a tool to generate an address that uses OP_CHECKLOCKTIMEVERIFY, but it only supports using one public key. This is different from just creating a transaction and adding a time lock to it. This transaction will be published and confirmed in the blockchain before it can be spent, not after.
As stated prior, nLockTime can only guarantee that the receiver cannot access the funds until a certain block... but it doesn't stop the sender from simply creating a new transaction to spend them, invalidating the original nLockTime transaction. So, I would agree that 2-of-3 MultiSig seems to be the solution here... using a trusted 3rd party to hold the 3rd private key.
Funds could be put into the multi-sig address now, effectively "locking" them, and when block# 585,500 arrives, the trusted 3rd party can co-sign a transaction to move the funds or release the 3rd key to the appropriate party, so that they can move the funds themselves.
Either that... or just send the funds to an escrow with instructions to not release until block# 585,500
Funds could be put into the multi-sig address now, effectively "locking" them, and when block# 585,500 arrives, the trusted 3rd party can co-sign a transaction to move the funds or release the 3rd key to the appropriate party, so that they can move the funds themselves.
Either that... or just send the funds to an escrow with instructions to not release until block# 585,500
You could probably do with looking into atomic swaps if you want to make sure that neither party can move the funds for the 6000+ blocks.
If you use a time-locked transaction, unless the holder of the private key is trustworthy or you are deleting the private keys and are trusted in doing that by the other party then you can do the time locked transaction, but as pooya states, you can't have the transaction accepted by nodes until that block so you'll have to broadcast it once that block has passed.
The block time should probably be 1 block before the target too (afaik).
If you use a time-locked transaction, unless the holder of the private key is trustworthy or you are deleting the private keys and are trusted in doing that by the other party then you can do the time locked transaction, but as pooya states, you can't have the transaction accepted by nodes until that block so you'll have to broadcast it once that block has passed.
The block time should probably be 1 block before the target too (afaik).
remember that you can not "publish" or broadcast such a transaction to the network now because nodes will not keep these transactions in their mempool since based on your mentioned block heights you are choosing a block that is 6,383 far and it will take about 44 days to get there.
the only thing you can do is to sign and store the transaction locally and only broadcast it when the time comes and the transaction (based on the locktimes) becomes valid/mineable.
the only thing you can do is to sign and store the transaction locally and only broadcast it when the time comes and the transaction (based on the locktimes) becomes valid/mineable.
You can create a time-locked transaction.
You can lock the transaction until a given time or a block height is reached.
From: https://coinb.in/#newTransaction
Click Advanced Options then set Lock Time as it suits you.
If the number you entered is smaller than 500.000.000 it will be interpreted as block height. If it is greater, it will be interpreted as Unix time.
You can lock the transaction until a given time or a block height is reached.
From: https://coinb.in/#newTransaction
Click Advanced Options then set Lock Time as it suits you.
If the number you entered is smaller than 500.000.000 it will be interpreted as block height. If it is greater, it will be interpreted as Unix time.
No. The TX must be published now at current block height (579,116) and confirmed at 585,500.
Edit: The goal is that neither sender or receiver can spend the coins between block 579,116 and 585,500.
I think you can use nLocktime (time-locked transaction) for that, Edit: The goal is that neither sender or receiver can spend the coins between block 579,116 and 585,500.
but senders/signers can create a new non-locktime tx with earlier confirmation to invalidate that transaction
another option is using a time-locked address, confirmed now but cannot be spend before specified time
No. The TX must be published now at current block height (579,116) and confirmed at 585,500.
Edit: The goal is that neither sender or receiver can spend the coins between block 579,116 and 585,500.
Edit: The goal is that neither sender or receiver can spend the coins between block 579,116 and 585,500.
You could make the tx with a extremely high fee (to be one one of the highest tx fees) right before this specific block (so, 584,499). Other than that, I don’t see what you could do.
Wish to make a TX that is published now, but confirmed at a given block height.
Current block: 579,117
Wish to confirm at: 585,500
How?
Current block: 579,117
Wish to confirm at: 585,500
How?
Jump to: