Topic: spend P2SH redeem script - page 2. (Read 467 times)

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