how to broadcast a trans with lock time?

[okbaby123]

I try to broadcast a trans with locktime

But when I set the locktime which is later than current time it is failed to broadcast

And sent it earlier than current time (or block) it works , but it doesn't make sense, if so.

Anyone can help.

To the mannul  https://bitcoin.org/en/developer-guide#locktime-and-sequence-number

It should work.

[1715233708]

1715233708

[1715233708]

1715233708

[1715233708]

1715233708

[cr1776]

I try to broadcast a trans with locktime

But when I set the locktime which is later than current time it is failed to broadcast

And sent it earlier than current time (or block) it works , but it doesn't make sense, if so.

Anyone can help.

To the mannul  https://bitcoin.org/en/developer-guide#locktime-and-sequence-number

It should work.

Check out, these, they may explain it better:

http://bitcoin.stackexchange.com/questions/26937/nlocktime-transactions-how-do-they-persist-are-they-broadcast-before-they-are
And:
https://bitcointalk.org/index.php?topic=23501.0

Particularly: "In other words: the responsibility of keeping a copy of the transaction and broadcast that when it's time, lies with whoever is interested in making the transaction (probably the recipient)"

In short, you broadcast after the lock time.

[arulbero]

https://github.com/bitcoin/bitcoin/blob/98f4c6c49ce42f3c83d21e5b8ae32eda02a79d49/doc/release-notes/release-notes-0.9.0.md  -->

Accept nLockTime transactions that finalize in the next block

[okbaby123]

In short, you broadcast after the lock time.

Nice in short explanation.

So the following story will happen:

Jack:" hey, lovely girl , I want to marry you and this is mine signed transaction, I will give you 1000btc one year later， you can verify it"

and Jackfucked Rose 364 days.

The 365th day Rose wake up and try to get those 1000btc but find the transaction invalid, Jack moved it to another address yesterday night. and..............Jack disappeared...............maybe saying same thing to Rose2..................



Story over. " promise is nothing , the nLocktime is a fucked idea in the design of bitcoin"

where are applause？

[achow101]

In short, you broadcast after the lock time.

Nice in short explanation.

So the following story will happen:

Jack:" hey, lovely girl , I want to marry you and this is mine signed transaction, I will give you 1000btc one year later， you can verify it"

and Jackfucked Rose 364 days.

The 365th day Rose wake up and try to get those 1000btc but find the transaction invalid, Jack moved it to another address yesterday night. and..............Jack disappeared...............maybe saying same thing to Rose2..................



Story over. " promise is nothing , the nLocktime is a fucked idea in the design of bitcoin"

where are applause？

Instead of using nLocktime, you should create a P2SH address that uses OP_CHECKLOCKTIMEVERIFY. Done correctly, the Bitcoin sent to that address cannot be moved until after the locktime. This doesn't have the issues of the nLocktime transaction not being sent.

[arulbero]

Locktime allows signers to create time-locked transactions which will only become valid in the future, giving the signers a chance to change their minds.

If any of the signers change their mind, they can create a new non-locktime transaction.

A time-locked transaction is not a promise! It's more like a (post-dated) check. If you don't trust the signer, you shouldn't accept his check.

[cunicula]

nLock is a bad idea indeed , it will just discard other nLockTime transactions. Since most miners run bitcoind or some fork of bitcoind, it is unlikely that an nLockTime transaction will persist for a long time.

More could be found here: http://bitcoin.stackexchange.com/questions/26937/nlocktime-transactions-how-do-they-persist-are-they-broadcast-before-they-are

[gmaxwell]

nLock is a bad idea indeed , it will just discard other nLockTime transactions. Since most miners run bitcoind or some fork of bitcoind, it is unlikely that an nLockTime transaction will persist for a long time.

More could be found here: http://bitcoin.stackexchange.com/questions/26937/nlocktime-transactions-how-do-they-persist-are-they-broadcast-before-they-are

That answer is confused.  Locked transactions cannot be relayed until they're about to become mineable. After they are mineable they hang around just as long as any other transaction, their persistence is not reduced.


The "story" doesn't make a lot of sense, however. If someone is going to give 1000 BTC  a year later with no opportunity to take it back, then that is the same as handing over the funds now.  All of locktime, cltv, and CSV make sense only if there are cases where the transfer would potentially be changed but is otherwise guaranteed.

Let me make it make sense:

For example, your rich uncle says he will pay you 1000 BTC if you get married and stay married for a year.  You don't believe him since he didn't get rich by being generous or trustworthy.   So he sends 1000 BTC to a 2 of 3 multsig, with him, you, and the editor of your local paper as signers. Additionally, he writes a transaction spending that payment and paying you directly, locktimed a year from now, and he signs it and gives it to you.  You sign it, so the only think keeping it from being valid is the locktime, and stick a few copies in safe places.  You go and get married, confident that your uncle will not have an easy time cheating you.

Now, at any point from between now and a year from now you might get divorced and then you can sign a txn giving the funds back, or-- assuming you don't co-operate he can go to the newspaper editor with evidence of your divorce, and get the funds back.

Otherwise, in a year, you can take that locktimed transaction and send it to the network-- with no further cooperation from anyone else.  That surprise forklift accident that got your uncle AND the newspaper editor will be no problem for you, their help is no longer required.

In this case the locktime was quite useful-- and there was no reason to send it to the network until the lock was already mature... which is exactly what the network expects.

If the network didn't work this way, people could make locked transactions that wouldn't be good for 100 years, use the network for free forwarding and storage.. then double spend the coins before the lock became mature to avoid paying any fees.  Fortunately, there are no interesting protocols that I've encountered where this is an issue.