Topic: spend P2SH redeem script (Read 467 times)

I got looking into 1PE3udPhhcSP4RAkVVuTPwQrGidVtkcaA4 when I saw https://x.com/MichaelDunwort1/status/1635424260314525696 | https://archive.ph/EjMaJ#selection-499.93-499.127

Shortly after I had clicked on Like on a bunch of tweets by https://x.com/MichaelDunwort1, they sent me a DM.

99 out of 100 DMs that I've ever received on Twitter are scammers.  Usually once I do a bit more research on them, I figure out they are scammers, block/mute them and move on.

In this case, a web search found this topic as the only match with bitcoin address 1PE3udPhhcSP4RAkVVuTPwQrGidVtkcaA4.

Does anyone know if https://x.com/MichaelDunwort1 is legit?  Either that is a legit account and he's a crafty bitcoiner, or scammers have reached a whole new level of ingenuity.

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.

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.

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

On transactions, not on addresses.

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.

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:
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!

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

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.

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.

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

---

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.

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.

Normal wallets don't create addresses with a timelock in 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.

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?

How can this shit happen by mistake? You can't just "find out there's a timelock", you need to consciously specify 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..
This shit can happen.

Correct, but that doesn't affect me. There's nothing stopping anyone doing all manner of stupid things with their bitcoin, like locking it behind scripts which are impossible to ever unlock, or burning it entirely. But no one can lock up bitcoin they are sending me unless I first agree to it by creating such a timelocked address in this case (or via covenants in the future, etc.)

No, people can send funds to any address with a timelock on it.

I was leaving out the step of faking a wallet with that address in it, like the 'password protected' ones, just doing it differently. Thought it was implied. It's a look I messed up and can't get to these coins since they are time-locked, here is a script here is a wallet with the address in there. (What you can't read my mind....)

Anyway I think this particular scam has been outed, at least for now.

-Dave

This address (39QWbnkbcPFcrJFEB6yvVDc12eX5zqVt3y) doesn't have a private key though: It has an unlocking script, the details of which I've given above. The private key needed in the script is the one belonging to the uncompressed public key in the script, which leads to the address 1PE3udPhhcSP4RAkVVuTPwQrGidVtkcaA4.

If you try to sell someone that private key, they will see an empty (although previously used) address. To lead them to the given address you'd need to first teach them about scripting. And if they can understand the script well enough to generate the given address, then they'll see through the scam.

Either a massive screwup / typo when doing something OR exactly what I said, invest BTC0.5 to get BTC2.0 as you sell it for BTC0.01 to 200 people.
I'll keep saying it, never underestimate greed and stupidity.

How many obvious scams do we see here day in and day out.
Add to that telegram and what's app and everything else I can easily see getting a couple of hundred people to pay.

-Dave

One problem: the buyer can sell it too

Second problem: the buyer won't understand how to use this private key, and thus can't easily verify it belongs to that address. Considering OP's history on this forum, I don't think he created this on his own. Which means that whoever created it spread it already. This address is mentioned on Reddit in a 2 years old post, but it doesn't add anything. I'm curious what's the story behind this.

But it is an interesting way to scam. Create said address, send funds to it, keep selling the private key.
P. T. Barnum:

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

As Loyce says, don't create the address in the first place.

As I explained above, the address in question is generated from a script which contains a timelock. For you to have such an address, you would have to specifically create it. It's not the case where a regular address can be turned in to a timelocked address, nor for me to send coins to your regular address and specify how or when you are allowed to spend them in the future.

This was a mistake on behalf of the person who created that address, not on behalf of the person who sent coins to that address.

That's easy to avoid: don't create addresses with a vicious timelock

So, how can one avoid a situation like this where people send money to your address with a vicious timelock.

If you look at the OPs posts they are all about getting coins from wallets / private keys.

https://bitcointalksearch.org/topic/btc-privatekey-with-lost-the-last-6-characters-5438141
https://bitcointalksearch.org/topic/selling-85-btc-walletdat-from-bitcoin-core-5260282
https://bitcointalksearch.org/topic/sell-walletjason-with-6000-eth-with-lost-password-5414773
https://bitcointalksearch.org/topic/help-get-rzs-value-error-offer-bounty-if-recover-btc-5416193

And so on.

IIRC the original transaction was discussed back when it was created, but it could have been another one with a really long lock by a script. There are a couple of them out there.
Wonder if it's a mistake or for some other reason.

-Dave

In case it isn't clear enough yet, your transaction is invalid until block 7,140,000.

Did you write this yourself? I mean, individually, without using some reputable wallet software. Or did you use such, but deliberately entered 7140000 in the LockTime field? Seems to me like you wanted 714,000 and an extra zero slipped through you. 

Take the script OP shared above:


Breaking that down, we get the following:

48   -   Size of script (72 bytes)
30   -   Header byte indicating signature
45   -   Push 69 bytes to the stack
02   -   Header byte for R
21   -   Length of R (33 bytes)
00a6....460c   -   R
02   -   Header byte for S
20   -   Length of S (32 bytes)
3f87....292e   -   S
01   -   SIGHASH_ALL
--------------------------------
49   -   Size of script (73 bytes)
03   -   Push 3 bytes to the stack
a0f26c   -   Little endian encoding of 7,140,000
b1   -   OP_CHECKLOCKTIMEVERIFY
75   -   OP_DROP
41   -   Push 65 bytes to the stack
0453....a2b2   -   Uncompressed public key
ac   -   OP_CHECKSIG

Looking at the second half of this script - if we haven't hit the necessary block as specified, then OP_CHECKLOCKTIMEVERIFY will terminate the script with an error. If we have reached the necessary block, then OP_CHECKLOCKTIMEVERIFY will verify, OP_DROP will clear the stack, and then all that is left will be the pubkey and OP_CHECKSIG as it would be in a old school P2PK output.

Now, if we take that part of the script:

Take the RIPEMD160(SHA256(script)):

Add the network byte 0x05, and then compute and append the checksum:

And then encode in Base58:

So all coins sent to the address 39QWbnkbcPFcrJFEB6yvVDc12eX5zqVt3y are locked by the above script, meaning they can only be spent when we hit block 7,140,000.

Yes.

Basically the same as: https://coinb.in/#newTimeLocked
Tick "blockheight", then set 7140000 in the blockheight box below it.
As the matter of fact, it produces the same script which uses pubKey in contrary to others which uses pubKeyHash.

This goes above my head... Does this mean someone created an input that's impossible to spend this century?

Yours is actually standard in the current protocol but your nLocktime isn't less than the LOCKTIME_THRESHOLD which made it "lock-by-blockheight".
So you'll have to wait for block height 7140000 or the Bitcoins locked in that script cannot be spent.

It's a different scenario this time since they do not have to change anything in Bitcoin to include the "uncompressed SegWit" transaction in their block.
All they had to do is accept that said transaction to their mempool to be included to their block.

Only miners with nodes before BIP-65 implementation may consider your transaction non-standard but valid;
But AFAIK (CMIIAW), the block will be rejected by new nodes.

Unfortunately, the "7140000 locktime" isn't the transaction's locktime but the locking script's.

For reference, here's the input's Redeem Script:

That might have been an uncompressed Segwit input, that's different.

Option 1: whoever has access to 39QWbnkbcPFcrJFEB6yvVDc12eX5zqVt3y can create a new transaction.
Option 2: if you own 3QNHG5gAs2pfLFQUsNnoCh8UjHoX9cZBEa, you'll have to wait about 125 years (and hope the owner of the sending address doesn't move the funds before that).
Option 3: petition for Bitcoin to mine blocks faster.

So, what's the story behind this transaction? Someone's pranking you?

thanks all...closed