spend P2SH redeem script

[Jason Brendon]

This shit can happen.

How can this shit happen by mistake? You can't just "find out there's a timelock", you need to consciously specify it.

How do you mean. I have an address to which people send money. I see money come in from my wallet, but at that moment i don't know if a timelock is on it, do I?

[1714283638]

1714283638

[1714283638]

1714283638

[1714283638]

1714283638

[LoyceV]

How do you mean. I have an address to which people send money. I see money come in from my wallet, but at that moment i don't know if a timelock is on it, do I?

Normal wallets don't create addresses with a timelock in it.

How about this? You are busy with something and someone wants to buy something from you. And with very limited access to the network, you check your address to see, ok the funds arrived, then you released the goods but it's too late to find out there is actually a 100years timelock on it..

If your customer paid, you'll have to release the goods. It's not the customer's fault you can't access your money until the next century.

[ABCbits]

This shit can happen.

How can this shit happen by mistake? You can't just "find out there's a timelock", you need to consciously specify it.

How do you mean. I have an address to which people send money. I see money come in from my wallet, but at that moment i don't know if a timelock is on it, do I?

If the wallet generate P2PK, P2PKH or P2WPKH address i can be 100% sure there's no timelock or other custom condition to spend it. On top of that, there are almost no Bitcoin wallet which support timelock feature.

[NotATether]

If the wallet generate P2PK, P2PKH or P2WPKH address i can be 100% sure there's no timelock or other custom condition to spend it. On top of that, there are almost no Bitcoin wallet which support timelock feature.

Pretty much only the Bitcoin Core command-line supports it. Not even their GUI wallet lets you do that.

How about this? You are busy with something and someone wants to buy something from you. And with very limited access to the network, you check your address to see, ok the funds arrived, then you released the goods but it's too late to find out there is actually a 100years timelock on it..

If your customer paid, you'll have to release the goods. It's not the customer's fault you can't access your money until the next century.

Merchants should not be accepting time-locked txid's for usual business, and should just refund any that they receive to the original address(es) - though that becomes more complicated if there are multiple inputs and outputs, so it's not automatically clear where the refund should go to. In that case, it's best for the customer to write an email to the merchant with the txid they sent, as for a refund, and supply their address.

It will simplify things for them to have a "no timelocked transactions" policy on their terms of service, and an "if you send us a timelocked transaction, we will not process it so please email us for refund instructions" clause.

[LoyceV]

Merchants should not be accepting time-locked txid's for usual business, and should just refund any that they receive to the original address(es) - though that becomes more complicated if there are multiple inputs and outputs, so it's not automatically clear where the refund should go to. In that case, it's best for the customer to write an email to the merchant with the txid they sent, as for a refund, and supply their address.

It will simplify things for them to have a "no timelocked transactions" policy on their terms of service, and an "if you send us a timelocked transaction, we will not process it so please email us for refund instructions" clause.

As long as the merchant doesn't create a timelocked address, this isn't a problem, right? If the buyer has a timelocked address, he can't get an on-chain confirmation from that address.

[o_e_l_e_o]

It will simplify things for them to have a "no timelocked transactions" policy on their terms of service, and an "if you send us a timelocked transaction, we will not process it so please email us for refund instructions" clause.

You are confusing different concepts here, I think. There are timelocked addresses and timelocked transactions.

In the case being discussed here, the address itself is timelocked by nature of the OP_CHECKLOCKTIMEVERIFY code in the script. Only the person who owns the address can set up an address in this way. Any and all coins sent to such an address cannot be spent until after the specified block height or Unix time.

Then you have transactions which can be timelocked by nature of the nLockTime field in the transaction. Only the person(s) who is creating the transaction can set up a transaction in this way. The transaction cannot be broadcast until after the specified block height or Unix time is reached.

A merchant doens't need a "no timelocked transactions" policy. They simply won't set up a timelocked address locking themselves out of their own coins (because why would they?), and since timelocked transactions cannot be broadcast until after the timelock has expired, if someone tries to send money this way either the merchant will receive it normally, or the transaction won't broadcast at all.

[Jason Brendon]

This shit can happen.

How can this shit happen by mistake? You can't just "find out there's a timelock", you need to consciously specify it.

How do you mean. I have an address to which people send money. I see money come in from my wallet, but at that moment i don't know if a timelock is on it, do I?

If the wallet generate P2PK, P2PKH or P2WPKH address i can be 100% sure there's no timelock or other custom condition to spend it. On top of that, there are almost no Bitcoin wallet which support timelock feature.

I don't think so. Electrum wallet has a feature that places a timelock.

[Jason Brendon]

It will simplify things for them to have a "no timelocked transactions" policy on their terms of service, and an "if you send us a timelocked transaction, we will not process it so please email us for refund instructions" clause.

You are confusing different concepts here, I think. There are timelocked addresses and timelocked transactions.

In the case being discussed here, the address itself is timelocked by nature of the OP_CHECKLOCKTIMEVERIFY code in the script. Only the person who owns the address can set up an address in this way. Any and all coins sent to such an address cannot be spent until after the specified block height or Unix time.

Yes, exactly! That's what i was trying to say. Not the address, but the nLockTime field in the transaction.
But what do you mean by:

since timelocked transactions cannot be broadcast until after the timelock has expired, if someone tries to send money this way either the merchant will receive it normally, or the transaction won't broadcast at all.

Cannot someone send money to the merchant's address with a vicious timelock that the merchant may not be able to spend it this life?

Thanks!

[o_e_l_e_o]

I don't think so. Electrum wallet has a feature that places a timelock.

On transactions, not on addresses.

Cannot someone send money to the merchant's address with a vicious timelock that the merchant may not be able to spend it this life?

Not possible.

If I create a timelocked transaction which cannot be spent for 100 years, then I won't be able to broadcast that transaction since all nodes will reject it until after the timelock has expired. The transaction won't be accepted to the mempool, so the transaction won't even show up as unconfirmed (let alone as confirmed) - it will simply be rejected as invalid. As far as the merchant is concerned, you haven't paid and so they won't release the goods.

[Jason Brendon]

I don't think so. Electrum wallet has a feature that places a timelock.

On transactions, not on addresses.

Cannot someone send money to the merchant's address with a vicious timelock that the merchant may not be able to spend it this life?

Not possible.

If I create a timelocked transaction which cannot be spent for 100 years, then I won't be able to broadcast that transaction since all nodes will reject it until after the timelock has expired. The transaction won't be accepted to the mempool, so the transaction won't even show up as unconfirmed (let alone as confirmed) - it will simply be rejected as invalid. As far as the merchant is concerned, you haven't paid and so they won't release the goods.

Ok... that explains everything. Thanks a lot. I was worrying, apparently i was wrong 

[Jason Brendon]

Think about it, how many people are greedy and just don't know that this really cannot be undone.
If the person who created this and sent the funds to it sold it 100 times between $500 and $1000 they have made a lot of money.
Sigh....humanity.....

-Dave

hi dave, but what's the point in doing so? if he locked 5 btc in the address placed with a timelock to a forever future, he himself can't have it.
Let's say he can, so can the others who it was sold to with the private key.

[ranochigo]

hi dave, but what's the point in doing so? if he locked 5 btc in the address placed with a timelock to a forever future, he himself can't have it.
Let's say he can, so can the others who it was sold to with the private key.

Tons of reasons, controlling their own impulse, keeping it for long term investment, etc. The whole point of a time lock address is to ensure that no one can have access to the coins without waiting until the specified time frame. Private keys are not meant to be sold or traded, it is not wise to purchase any private keys. It would just mean that multiple people will have access to the coins when the time comes and whoever moves the coins first when the timelock expires will get the coins.