Is this P2SH _obviously_ vulnerable? [0.1 tBTC stake]

[BTCW]

A vulnerable P2SH address - but how vulnerable?

I have been fooling around some more with custom P2SH addresses. Got a new one for you: 2N3jiV8cRVN8y8Vgn2wvTW24zPsDX5dKjGT

(Yeah, testnet only this time around, but the principals are identical.) Edit: real BTC added, see below.

You can look it up here or here, for example.

The address had been funded once with 0.1 tBTC. It has then been spent from once (hint!).

I sent 0.1 tBTC to it again, waiting for it to be plucked.

Can and will you snatch it?


If it is successfully emptied by someone, who won't write here about how they didn't, I'll do it.

If no one is able to rob it, which I doubt given the expertise on this forum, I will take it back in a day or two - then tell you all about it.

Win-win?


Give it a shot!

[1714785975]

1714785975

[1714785975]

1714785975

[1714785975]

1714785975

[1714785975]

1714785975

[COBRAS]

http://joncave.co.uk/2014/08/bitcoin-sighash-single/

https://arnaudbrousseau.com/notes/feeling-lucky-how-to-steal-bitcoins.html

[pooya87]

Is this P2SH _obviously_ vulnerable?

obviously! as soon as the signature script is provided it becomes vulnerable.
i think you did it a couple of times before too. so i'm not sure what's the point of this new one here since it is basically the same thing but this time with hash related OP codes.

[TheArchaeologist]

Can't you just do your little experiments on regtest? Then if you wan to make it a real challenge do it on mainnet. But don't be suprised the funds will be gone soon then.

[BTCW]

OK, OK - I hear you! Loud and clear. Testnet coins have per definition no value. So I just added real value.

I convinced my crew to send 0.001 BTC - the real deal (slightly north of 10 USD at the time of writing) to: 3CBWRPgPsudcvi4EMpJat55jBX1MF7wwX6

txid: d215a14a205fa14cd6106e23fe9e4d8399fb15aa6c6ac026478cb63dc9811be1

If you can spend from the testnet address above, you can spend from this mainnet address. Compare the hash160 of the testnet and mainnet addresses; they should be identical - in other words: spendable using the same recipe.

So, go ahead and grab the real coins (and the testnet ones while you're at it, if you want), and please describe here how you did it.


What I meant with "obviously vulnerable" is: if you say this transaction fly by when you were manually overseeing the mempool - as every normal person does 24/7 - is it really that obvious that you just stumbled upon an anyone-can-spend address?

[pooya87]

What I meant with "obviously vulnerable" is: if you say this transaction fly by when you were manually overseeing the mempool - as every normal person does 24/7 - is it really that obvious that you just stumbled upon an anyone-can-spend address?

it isn't that hard to write a simple script that looks at all transactions it (the node) receives and double spend them if they were vulnerable (aka spendable by anyone). for starters a script that doesn't have any of the CheckSig OPs is a good candidate for being vulnerable.
but it wastes time and money running such script that isn't really worth it since it is not early days and the bitcoin value is so high nobody does experiments like that.

interesting on-chain experiment though. whoever spent this output, set the fee to ~30x higher than what they should have paid for high priority tx and didn't use RBF which makes double spending a lot harder. and probably there weren't any attempts or blockcypher would have shown them (although it is not certain) https://live.blockcypher.com/btc/tx/2ebe391033f7980994e66ad63c274f9e9656ff43c72313ae2d52b9945f2d4b9f/

[BTCW]

Concluding remarks

Here is a brief explanation of how and why the posted addresses are vulnerable, so-called anyone-can-spend, and this is not intended for those of you who already figured it all out - at least one person did, since the coins are swept - but for the rest of you. (After this, I promise to take it easy with further P2SH-jibberish, unless I cook up a new angle not covered before.)

OK, so in order to spend from an address, or rather a UTXO, you need a Sigscript that, when it is hashed, matches the public address, which is proof of ownership that allows you to create and broadcast a valid transaction. (This is a grave oversimplification, but I think it suffices for now.)

A Sigscript, in turn, is divided into an unlocking script and a locking script, that are added together in that order, then executed and evaluated. So, not only does a Sigscript need to make mathematical sense (i.e. return the desired hash), it must make programmatical sense too (i.e. the code is actually run and must return "TRUE" [defined as a "clean" stack, containing a positive integer top value, and nothing else].

The locking script corresponds, if you will, to the padlock (and, nonetheless, unambiguously to one defined public address) which can only be opened by the right key (or keys - let's not go there for now), which is the unlocking script.

What I did here was creating this quite nonsensical locking script:

Code:

#locking script
OP_DUP
OP_DUP
OP_DUP
OP_DUP
OP_RIPEMD160
20 0xc32570171b6234e158dfe6a05e4b2648fbfd36e5
OP_EQUALVERIFY
OP_SHA1
20 0x017665afd86034088ecfb0a936eaa0f2dae8b60d
OP_EQUALVERIFY
OP_SHA256
32 0x67182f446b2512c6f7abe26a7073ae9abb95c3ddbfb0d746c74fad9f6250507a
OP_EQUALVERIFY
OP_HASH160
20 0x8fb2bfa8d595dce0a2444bf5490f494bb08894f5
OP_EQUALVERIFY
OP_HASH256
32 0x980addf8c77cd6d996cb47565a5fcc869f4552e4f509495a5ff6314ef09212ed
OP_EQUAL

What it does it that it takes a simple input (push), duplicates it four times so there are five copies in the stack, and hashes them with all five different hashing methods that are the Bitcoin script language contains, and compares them, sequentially, with hardcoded values. (That's why I call it "nonsensical" because you have to surrender the full solution, visible by all, to spend, so that anyone who analyzes the blockchain, the public ledger, can recycle the key again and again - there are no signatures involved in any of the steps.)

This means that you "only" need to find the one value that unlocks it. And admittedly, I thought I was a little clever when I took a random transaction from the blockchain, and copied the so-called witness program from it, and used that data as the unlocking code (the hardcoded values in the locking script are the five different hashes of this input, which I precomputed):

Code:

#unlocking script
OP_PUSHDATA1 104 0x30440220387157915c57edba6b745cfc2087bad1f27fa76c2519c21391890aa559d801fe0220313e4929d94ac513540d091816f47ae2b4e09222f41b17d2af70b1297378272c01037364148a47880aa6c2980af699a9ee46531818cd4c483c48d3f2aef387f328ba

(There are a couple of length bytes you need to throw in to make this work, and one opcode that must be pruned, but I won't go there for now.)

In other words, I tried to disguise an any-one-can-spend address by having it require data that looks like a witness program but is in fact just a data push - hence my "is it obvious"-question.

The locking script corresponds to exactly 3CBWRPgPsudcvi4EMpJat55jBX1MF7wwX6 on the Bitcoin mainnet and 2N3jiV8cRVN8y8Vgn2wvTW24zPsDX5dKjGT on the Bitcoin testnet. (I have posted multiple times about how to convert scripts into P2SH addresses with a few lines of Python, so let's skip that too.)

Well. That's about it.

I could write in great length about how to manually construct a valid transaction hexadecimal string that you can broadcast in Electrum, Bitcoin Core GUI, or via a number of web pages, but it is beyond the scope and limitation here. Also, others have written about it much better than I ever could. If you're not a big fan of assembling raw transactions in Notepad++, check out for example coinb.in that can do it for you, given the right inputs.

We good?


P.S. Yeah, the transaction fee someone coughed up for the mainnet satoshis is pretty crazy, agreed. We can choose to see is positive: 10k sats were given back to the community (well, the miner of the block, but... yeah.)

[NotATether]

In other words, I tried to disguise an any-one-can-spend address by having it require data that looks like a witness program but is in fact just a data push - hence my "is it obvious"-question.

Can you explain how an address can be spent by anyone without revealing its private key? From reading your answer it looks like if you make the locking script and unlocking script push the same data then the input can be spent, but I think my reasoning is wrong. And is it possible for someone to create exposed P2WSH and P2WPKH addresses too?

[pooya87]

Can you explain how an address can be spent by anyone without revealing its private key? From reading your answer it looks like if you make the locking script and unlocking script push the same data then the input can be spent, but I think my reasoning is wrong. And is it possible for someone to create exposed P2WSH and P2WPKH addresses too?

bitcoin works by utilizing locking and unlocking scripts. each time you create a new transaction you are providing the unlocking script to the coins you received while creating new locking scripts that the receiver has to unlock. you can think of these as conditions that needs to be met too.

a bitcoin address is the human readable form of a handful of these predefined locking scripts.

so how can it be spent without a private key? by providing a script that doesn't have any CheckSig OPs in it (there is an exception for this too). for example a simple locking script can be this:

Code:

OP_ADD OP_8 OP_EQUAL

this needs an unlocking script (a signature) that has 2 numbers that when added are equal to 8.
so anyone can provide the answer (0+8 or 1+7,...) and "unlock" this script aka spend the coins.

to turn this into an address this locking script could be wrapped in a P2SH so that it hides what the script is by only providing its hash then the signature script should contain both the unlocking script and the script posted above now called redeem script.

P2WSH is the same as P2SH in the sense that it is paying to the hash of an arbitrary [redeem] script but it is using SegWit (the signature is placed in witness).
P2WPKH is an entirely different address and represents a certain script that contains an OP_CHECKSIG so it can't be used like this.

[ranochigo]

There's a simpler example of this quite some time ago[1]. The example has SHA256d of the genesis block hash as the solution for the unlocking script. It's a much more simplified and obvious puzzle as compared to OP's as it only involves one SHA256d hash.



[1] https://en.bitcoin.it/wiki/Script#Transaction_puzzle

[pooya87]

There's a simpler example of this quite some time ago[1]. The example has SHA256d of the genesis block hash as the solution for the unlocking script. It's a much more simplified and obvious puzzle as compared to OP's as it only involves one SHA256d hash.

i don't think the two are not comparable though. if you look at that puzzle, it is actually a puzzle because there are clues. with a quick look at the hash you can get ideas (hint it has zeros at the end just like a block header hash does)

Code:

6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000

however if you look at the hash OP's case releases there is no hint at all.

Code:

7314b17476dbbfdabdbf76f627870cbce89a19c0

the only way to solve this is for him to first release the redeem script and someone else copies it.

[BTCW]

In other words, I tried to disguise an any-one-can-spend address by having it require data that looks like a witness program but is in fact just a data push - hence my "is it obvious"-question.

Can you explain how an address can be spent by anyone without revealing its private key? From reading your answer it looks like if you make the locking script and unlocking script push the same data then the input can be spent, but I think my reasoning is wrong. And is it possible for someone to create exposed P2WSH and P2WPKH addresses too?

Yeah, there is nothing that says that every Bitcoin public address must be unlocked with a signature, which in turn is derived from a private key.

For the addresses I created here, there is no (known) private key. In fact, not even the public key is known (which, again, is not the same as the public address).

There is no real cryptography for these "stupid" P2SH addresses. (In no step do we involve elliptic curve cryptography, which is more or less the backbone for "real" or proper Bitcoin-use.)

[BTCW]

There's a simpler example of this quite some time ago[1]. The example has SHA256d of the genesis block hash as the solution for the unlocking script. It's a much more simplified and obvious puzzle as compared to OP's as it only involves one SHA256d hash.

i don't think the two are not comparable though. if you look at that puzzle, it is actually a puzzle because there are clues. with a quick look at the hash you can get ideas (hint it has zeros at the end just like a block header hash does)

Code:

6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000

however if you look at the hash OP's case releases there is no hint at all.

Code:

7314b17476dbbfdabdbf76f627870cbce89a19c0

the only way to solve this is for him to first release the redeem script and someone else copies it.

Did the creator of this puzzle reveal the unhashed locking script?

Code:

OP_HASH256
32 0x6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
OP_EQUAL

If you are allowed to read it like so, I totally agree it contains a clue. But if only it was just a public address, which in this case computes to 36oqxNpxpsuTnfZiDdSYMJpdCKiNiuQ7ZN, from which you can only derive the hash160 padded with P2SH prefix and suffixes - 17a9 3823382e70d1930989813d3459988e0d7c2861d8 87 (spaces inserted for clarity), it is equally just as clueless (pun intended).

Edit: Aha, read up some, this was pre standard-P2SH-era, txid a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b, so the receiving address was non-standard. It was paid to a weird script (not hashed as a whole, genesis block hash clearly visible), that doesn't translate to a normal address. Not even today's block explorers can label it (and trace where it went?). Let's call it P2S and conclude such transactions are very rare.


Edit again: Yay! Was able to reproduce all of it on the testnet. P2S isn't dead!

Sent to script with Electrum (is it even possible in Bitcoin Core GUI?), txid: cfdf688febb0fec9bb77ccf9a6bdc28f39e9ba96fc74aeb5ff8e49a45dc077ca

Took it back by constructing a the below raw transaction and broadcast in Elecrum console, txid 0003bfd0743d36bcfcc405dd3ea2d2d1255166327c59b7e756dcc9cfc99802be

Raw transaction:

Code:

0100000001ca77c05da4498effb5ae74fc96bae9398fc2bda6f9cc77bbc9feb0eb8f68dfcf01000000524c500100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7cffffffff014c494c000000000017a914628cde58e1bcd42efb72b1821ec9fdf49e0f1d498700000000

Cool! Today I learned an UTXO does not necessarily belong to regular addresses, only a tx hash, that block explorers have a hard time figuring these out. P2S FTW!

[pooya87]

Cool! Today I learned an UTXO does not necessarily belong to regular addresses, only a tx hash, that block explorers have a hard time figuring these out. P2S FTW!

that's correct. at protocol level there is no such thing as "address", there are only scripts that depending on the pubkey script they are evaluated in different ways and have to end up with a "true" at the end indicating success (with some other conditions which i skip for simplicity).
the "address" is just he human readable form of pointing to a handful of predefined scripts.

[BTCW]

Cool! Today I learned an UTXO does not necessarily belong to regular addresses, only a tx hash, that block explorers have a hard time figuring these out. P2S FTW!

that's correct. at protocol level there is no such thing as "address", there are only scripts that depending on the pubkey script they are evaluated in different ways and have to end up with a "true" at the end indicating success (with some other conditions which i skip for simplicity).
the "address" is just he human readable form of pointing to a handful of predefined scripts.

Yup. "Just human-readable" includes about every block explorer, though. I don't think it is widely known, please do correct me if I'm wrong, that it is quite possible (and easy - Electrum GUI - as I did above) to hide away coins in UTXOs that do not translate to human-readable addresses.

"Everybody" is talking about Bitcoin privacy and anonymity, tumbling, washing, and methods of cracking the public ledger (blockchain) vs anonymity nut.

How about simply sending whatever you wish to hide to scripts that won't translate to public addresses as they are currently defined, as they cannot be tracked/traced by major block explorers on the web?

It would be a walk in the park to invent your own address system (say base57; not a serious proposal), refrain from sharing it with the public, for example but not limited to an Electrum plugin, and use it on-chain without the need for even a soft-fork. Is this already going on? If yes, where can I read more? If no, why?

[pooya87]

"Everybody" is talking about Bitcoin privacy and anonymity, tumbling, washing, and methods of cracking the public ledger (blockchain) vs anonymity nut.

How about simply sending whatever you wish to hide to scripts that won't translate to public addresses as they are currently defined, as they cannot be tracked/traced by major block explorers on the web?

unless the blockchain analysis code is written in a naive way, they don't follow addresses but instead follow "coins" aka the "transaction outputs" which means it doesn't matter if your output script is one of the standard ones (that has an equivalent address) or a non-standard one.

[BTCW]

"Everybody" is talking about Bitcoin privacy and anonymity, tumbling, washing, and methods of cracking the public ledger (blockchain) vs anonymity nut.

How about simply sending whatever you wish to hide to scripts that won't translate to public addresses as they are currently defined, as they cannot be tracked/traced by major block explorers on the web?

unless the blockchain analysis code is written in a naive way, they don't follow addresses but instead follow "coins" aka the "transaction outputs" which means it doesn't matter if your output script is one of the standard ones (that has an equivalent address) or a non-standard one.

It was easier said than done on the mainnet. The testnet experiment (above), i.e. sending to a custom script that isn't one of the predefined address formats, was easy. However, I fail to reproduce it on the mainnet.

Bitcoin Core and Electrum can both create and sign the transaction, but when broadcasting, they produce "Code: -26, Error: scriptpubkey".

Tried broadcasting the raw transaction via blockchain.com (here), which resulted in the same error code. Broadcasting via Blockcypher (here), which is known to be more a lot more promiscuous, was partially successful. It was accepted, but only picked up by a fraction of the nodes, so I deem it unlikely that this transaction will ever be mined and included in a block. This transaction does not propagate to any of the mempools for my other wallet software.

If the vast majority of the mainnet nodes think that sending to a non-standard script is a no-no, then I guess that's the end of that.

[pooya87]

If the vast majority of the mainnet nodes think that sending to a non-standard script is a no-no, then I guess that's the end of that.

yeah a lot of non-standard scripts are going to be rejected by all bitcoin core nodes with default setups right away on mainnet and only partially on testnet. it is a good thing too, it prevents malleability attacks, sending coins to broken scripts and lose funds,... but sometimes it is bad too, there is someone in tech support board that has a large amount of bitcoin (5-6 i think) stuck in a SegWit output that simply uses uncompressed public key.

[BTCW]

If the vast majority of the mainnet nodes think that sending to a non-standard script is a no-no, then I guess that's the end of that.

yeah a lot of non-standard scripts are going to be rejected by all bitcoin core nodes with default setups right away on mainnet and only partially on testnet. it is a good thing too, it prevents malleability attacks, sending coins to broken scripts and lose funds,... but sometimes it is bad too, there is someone in tech support board that has a large amount of bitcoin (5-6 i think) stuck in a SegWit output that simply uses uncompressed public key.

It is a little strange that the original puzzle transaction, referenced in the wiki - part of Bitcoin's history, is perfectly irreproducible today, with stricter enforcements of IsStandard() and IsStandardTx(), while at the same time these checks have been completely disabled for P2SH. For example:

Code:

OP_DROP
OP_TRUE

gives locking script "7551", which is translated to its 3-address by

Code:

>>> import binascii, hashlib, base58
>>> script='7551'
>>> base58.b58encode_check(binascii.unhexlify('05'+ hashlib.new('ripemd160', hashlib.sha256(binascii.unhexlify(script)).digest()).hexdigest())).decode()
'3L7zn1euXPcWoJC36Biw4yXee6F5ksEYdb'

And 3L7zn1euXPcWoJC36Biw4yXee6F5ksEYdb is perfectly legal to send to and spend from, still. To spend, push any single value as the unlocking code, the script will drop it and replace it with "TRUE".


Edit/addition

Have confirmed that the above works (caveat: testnet).

First, calculated the P2SH address for script "7551" (changed prefix from "05" to "c4" for testnet):

Code:

>>> import binascii, hashlib, base58
>>> script='7551'
>>> base58.b58encode_check(binascii.unhexlify('c4'+ hashlib.new('ripemd160', hashlib.sha256(binascii.unhexlify(script)).digest()).hexdigest())).decode()
'2NBgCqkaw8r7s15pamKLogvWurSTFVVf1Kf'

Second, sent 0.1 tBTC to 2NBgCqkaw8r7s15pamKLogvWurSTFVVf1Kf, txid: 6a9cf36bd72c2b1cba68182b65975a3be95f4aa345fe4c63986117e7489ed572

Third, manually created a raw transaction in which the key (literally) is the sigscript "0451027551", in which "04" is the length of it all, "51" is OP_1 (pushing 01 to onto the stack; this could, however, be any value), followed by "02" which is the length of the locking script and finally "7551" which is the locking script itself.

Broadcast successfully in Bitcoin Core GUI console with:

Code:

sendrawtransaction 010000000172d59e48e7176198634cfe45a34a5fe93b5a97652b1868ba1c2b2cd76bf39c6a010000000451027551ffffffff01869598000000000017a914628cde58e1bcd42efb72b1821ec9fdf49e0f1d498700000000

And so got it all back (well, minus transaction fees), txid: 20ecf01a6be6d9e103732e8ea05f5c504fc403de7cd3f96ca6df8c8853afd2f3

All good. I'm quite sure this is reproducible on the mainnet, but didn't feel like wasting real BTC tx fees for simply amending this post.