Can Bech32 be P2SH? [Bounty inside!]

[BTCW]

Some background

I have fooled around a bit with "stupid" scripts and their corresponding P2SH addresses ("3"-format). Have written about some findings for example here. (And to be clear, I don't mean so-called wrapped P2WPKH-P2SH addresses; those are "3-addresses" too, but on the contrary, do have a private keys, rely on ECC and so forth - very different from "pure" P2SH.)

To mention one, the stupid anyone-can-spend script "OP_1" is 0x51 in hexadecimal and is easily converted to the public address like so (Python 3):

Code:

>>> import binascii, hashlib, base58, bitcoinutils
>>> from bitcoinutils import bech32
>>> script='51'
>>> hash160 = hashlib.new('ripemd160', hashlib.sha256(binascii.unhexlify(script)).digest()).hexdigest()
>>> p2sh_b58 = base58.b58encode_check(binascii.unhexlify('05'+ hashlib.new('ripemd160', hashlib.sha256(binascii.unhexlify(script)).digest()).hexdigest())).decode()
>>> print(p2sh_b58)
3MaB7QVq3k4pQx3BhsvEADgzQonLSBwMdj

This public address, 3MaB7QVq3k4pQx3BhsvEADgzQonLSBwMdj, has at the time of writing 790 transactions.

Now, what is interesting is that you only need fundamental insights in Bitcoin raw transactions to spend from this address; here the most recent transaction out:

Code:

0100000001d34fe68a3c6054aae1e092fb5e395a7e72c99783a05c010d2be298e318a0248100000000020151ffffffff01080700000000000017a914a89aec4cd53e6d74215332459b7fea3ec4aca9758700000000

Now, you can't create such a transaction in Bitcoin Core or Electrum, but it is easy enough to do in Notepad++. The magic is the Sigscript

Code:

020151

right before the ffffffff separator, which it Bitcoin script for simply saying "push OP_1 onto the stack", and voilla - you control the coins.

No ECC or private key involved. Simple. And stupid. Because of its anyone-can-spend nature.


The real question - do Bech32 P2SH addresses exist?

Until just recently, I believed that all Bech32 addresses - the by-now-not-so-new "bc1" format - are either P2WPKH or P2WSH, which means they behave more or less like legacy address, and the only difference is that the raw transactions are constructed differently (the Sigscript must be empty and witness data must be presented as a new entity, after the receiving address - we call this segwit and it's pretty cool), but one sentence in the Bitcoin Wiki made me wonder:

https://en.bitcoin.it/wiki/List_of_address_prefixes

First table: "Bech32 pubkey hash or script hash" (my underlining)

What is this? Do they actually mean script hash (SH) and not witness script hash (WSH)? If so, then there are "real" Bech32 P2SH addresses, right? (Or is the wiki written sloppily?)

So, I did some testing and converted "stupid" scripts (like in the introduction) to their Bech32 addresses, using this code:

Code:

>>> p2sh_b32 = bitcoinutils.bech32.encode('bc',0,memoryview(binascii.unhexlify(hash160)).tolist())
>>> print(p2sh_b32)
bc1qmgt5t6d4fx7sh7s626vhr3m7hgcv6kjt450t6x

OK, so bc1qmgt5t6d4fx7sh7s626vhr3m7hgcv6kjt450t6x has to date never been used, suggesting this is uncharted territory.

But - I then tried a slight variation, i.e.

Code:

script = <short series of opcodes>

which led me to a Bech32 address that in early 2017 received more than 1 BTC.

For natural reasons, I will not write it out here, as they have never been spent.

The key question (pun intended) is then how one would go about spending from such an address. Because if we take a look at one typical spending from a Bech32 P2WPKH address, I picked this transaction - 4bce99b9f78fd0d5d7d52dd41b6c406577c59ee5f6105541683fe527f6c3f43c - randomly, its raw transaction is

Code:

0100000000010128746e138c008ca1c61ebd8d3b7d5d9e8e2d4375d59690661e3f70d0b1de8ca300000000000000000001c9896c000000000017a914269ef48bf373a19deaa94b32cae5cbe3c93062fb8702483045022100b893c9d2f1b2525e84e9bb31c016a65f4891f6a954fc1c0c1d06189bcc8ae65002205e1f3b5de07be06775cd141a4e1e187c41ad03a1c6955b21568079482aef8648012102a5daf09e8da80f53edca8c8e59a5f4a6363a7b94cfbffb9c9240d4b2e239d1dd00000000

Let's skip a few numbers and cut to the chase, the witness program (last in the serialized output, because of segwit). In this example it is (cheating by convering to a JSON object):

Code:

"witness": [
                "3045022100b893c9d2f1b2525e84e9bb31c016a65f4891f6a954fc1c0c1d06189bcc8ae65002205e1f3b5de07be06775cd141a4e1e187c41ad03a1c6955b21568079482aef864801",
"02a5daf09e8da80f53edca8c8e59a5f4a6363a7b94cfbffb9c9240d4b2e239d1dd" ]

Alright, clearly some signing has been performed here, using a private key. In the first instance, we fairly easily find the r- and s-values (after the code separator "02"), and the second instance is simply the public key (not to be confused with the public address).

Then we have a problem with the maybe P2SH Bech32 address I found - because I know its script, which means I cannot know either its public key or create signatures since there is no private key for it.

The big question is - is it spendable? I have been trying to read up on BIP173 and valid structures for segwit witnesses, but find the documentation vague and elusive.

Remember how easy it was to spend from the "normal stupid" P2SH address above by simply pushing 3 bytes of data in the Sigscript? For Bech32 and segwit, the Sigscript must always be empty, which creates an interesting obstacle.

Is possible to construct witnesses for what I know is a Bech32 address, or at least an attempt to make one, an address that has had more than 1 BTC untouched since 2017? The whole address is the product of one simple script, and there is no cryptography involved at all.

Is it possible to construct "stupid" "020151"-like witnesses for this address and assemble a valid raw transaction that can be broadcast without errors (i.e. accepted by the majority of the network), or is it simply so that Bech32 is never P2SH (despite what the wiki says)?

Looking forward to hearing your thoughts on this. (For what it's worth, I have a smaller collection of Bech32 P2SH addresses with positive balances according to the blockchain and it would feel bad if they were forever stuck there because of a programming error or something.)


TL;DR

Do Bech32 P2SH addresses exist, and if they do, how do you construct valid transactions from them? Many thanks!

[BTCW]

EDIT: UPDATED

Let's make it a bounty! Of course!

I created this stupid script "OP_1 OP_DROP OP_1" (a typical any-one-can-spend)

Code:.

Code:

*deleted*

and convinced a friend to fund it, tx id 1d0e1340dc6f273de3a4a84cb464ac7f3c4b5aff9201571028aa8bdf9cd1609e

Show us it can be done! Don't forget to show us the raw transaction. Keep the change, 50k sat. Cheers


NEW:

I created this stupid script "OP_2" (a typical any-one-can-spend)

Code:

Code:

>>> script='52'
>>> hash160 = hashlib.new('ripemd160', hashlib.sha256(binascii.unhexlify(script)).digest()).hexdigest()
>>> p2sh_b58 = base58.b58encode_check(binascii.unhexlify('05'+ hashlib.new('ripemd160', hashlib.sha256(binascii.unhexlify(script)).digest()).hexdigest())).decode()
>>> p2sh_b32 = bitcoinutils.bech32.encode('bc',0,memoryview(binascii.unhexlify(hash160)).tolist())
>>> print(p2sh_b58)
3BLfZAdt1syots4kATFfo8sXDk6WZS2YfN
>>> print(p2sh_b32)
bc1qd8t7lr6z5f0g0ydmxl2lkjz9dugz509edtdew3

and convinced a friend to fund bc1qd8t7lr6z5f0g0ydmxl2lkjz9dugz509edtdew3, txid: 1e91c1ded6fa1c661f632343c6eed7b3e67003c0d73d11d3c0adf9dd4ff6701e


Show us it can be done! Don't forget to show us the raw transaction. Keep the change, 50k sat. Cheers.

[achow101]

Yes, that's what P2WSH is.

Instead of putting things into the scriptSig as you do for P2SH and P2PKH, you use the scriptWitness. This is not a script but rather a stack. It's the equivalent of having a script that does PUSHDATA <data> PUSHDATA <data> ... but instead of pushing bytes to the stack, you just give it the stack directly. So any script that can be satisfied purely through pushes can be P2WSH.


BTW your bounty is actually completely incorrectly made and is actually unspendable. A segwit v0 scriptPubKey with the witness program (that's the data pushed after the version byte) of length 20 bytes is always P2WPKH. P2WSH uses a single SHA256 of the witness script (which is the redeemScript but for segwit) so the witness program is 32 bytes. By using the 20 byte hash160, you've made this output a P2WPKH output and thus only spendable if someone can figure out the pubkey that hashes to that hash and the private key for that pubkey.

[pooya87]

The big question is - is it spendable? I have been trying to read up on BIP173 and valid structures for segwit witnesses, but find the documentation vague and elusive.

BIP173 is explaining the bech32 encoding not the SegWit transaction structures. BIP-143 is also explaining the signing process. BIP-141 is mainly what you should check out.

in simple terms it is similar to how P2SH added new steps for script evaluation. when we see these new SegWit script structures (OP_number <data between 4 and 42 bytes>) we fire up those additional steps which are currently only defined for OP_0 which is version zero witness program.

[BTCW]

Still, no conclusive answer to the core question: Can a Bech32 be a P2SH-address? As the wiki seems to imply. If yes, how would you construct valid witnesses for it?

If the answer is "no - Bech32 can never be P2SH", then I guess the 1 BTC Bech32 address that I stumbled over is forever unspendable. (Since it was constructed exactly as described above.)

[BTCW]

[...]

BTW your bounty is actually completely incorrectly made and is actually unspendable. A segwit v0 scriptPubKey with the witness program (that's the data pushed after the version byte) of length 20 bytes is always P2WPKH. P2WSH uses a single SHA256 of the witness script (which is the redeemScript but for segwit) so the witness program is 32 bytes. By using the 20 byte hash160, you've made this output a P2WPKH output and thus only spendable if someone can figure out the pubkey that hashes to that hash and the private key for that pubkey.

I would like to challenge this. Since I am able to spend from 20-bytes "stupid" P2SH address 3MaB7QVq3k4pQx3BhsvEADgzQonLSBwMdj created with pseudocode (real code above)

Code:

base58check(ripemd160(sha256(OP_1)))

note especially that it contains no wrapping prefixes, so it is not P2WPKH-P2SH, it has no (known) private key or even public key - simply providing "020151" as Sigscirpt does it (proof).

So, the only change in this thread is pseudocode

Code:

bech32(ripemd160(sha256(OP_1)))

As there are several of addresses like this with positive balances on the blockchain - forever unspendable or not?

Edit/addition: Another phrasing of my question could be "is it possible to create an anyone-can-spend Bech32 public address (as you can do with 3-addresses)?"

[achow101]

I would like to challenge this.

Well I'm telling you you are wrong.

From BIP 141

If the version byte is 0, and the witness program is 20 bytes:

• It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program.
• The witness must consist of exactly 2 items (≤ 520 bytes each). The first one a signature, and the second one a public key.
• The HASH160 of the public key must match the 20-byte witness program.
• After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack.

The code does what the BIP says.

A Segwit v0 with a 20 byte witness program is always interpreted as a key hash. In segwit, we don't allow for the P2SH hash160.

As there are several of addresses like this with positive balances on the blockchain - forever unspendable or not?

Yes, forever unspendable. These are created by people who have made the same mistake you have.

Edit/addition: Another phrasing of my question could be "is it possible to create an anyone-can-spend Bech32 public address (as you can do with 3-addresses)?"

Yes, it is. I can make one on testnet if you'd like.

[BrewMaster]

Still, no conclusive answer to the core question: Can a Bech32 be a P2SH-address? As the wiki seems to imply. If yes, how would you construct valid witnesses for it?

your question is asked in a strange way but it is already answered by achow101 in the first line of his comment.
in other words, and a correct term, you can create a bech32 address from the hash of a script which would make the resulting address of type P2WSH and that hash (unlike the hash used in P2SH) is a single SHA256.

so to expand:

Code:

bech32(ripemd160(sha256(OP_1)))

this route will make a P2WPKH and makes the output unspendable^why?.
the correct route is this:

Code:

bech32(SHA256(OP_1))

^why? because that is how the protocol works. when the script interpreter sees OP_0 followed by 20 bytes (which is the same as short bech32 address you created) it expects a P2WPKH script and a single signature and single public key (2 items) in witness stack not a script. if you provide OP_1 it fails right away because your witness stack has only 1 item instead of 2 and if it tries converting 0x52 to a public key it obviously fails.

[BTCW]

I would like to challenge this.

Well I'm telling you you are wrong.

From BIP 141

If the version byte is 0, and the witness program is 20 bytes:

• It is interpreted as a pay-to-witness-public-key-hash (P2WPKH) program.
• The witness must consist of exactly 2 items (≤ 520 bytes each). The first one a signature, and the second one a public key.
• The HASH160 of the public key must match the 20-byte witness program.
• After normal script evaluation, the signature is verified against the public key with CHECKSIG operation. The verification must result in a single TRUE on the stack.

The code does what the BIP says.

A Segwit v0 with a 20 byte witness program is always interpreted as a key hash. In segwit, we don't allow for the P2SH hash160.

As there are several of addresses like this with positive balances on the blockchain - forever unspendable or not?

Yes, forever unspendable. These are created by people who have made the same mistake you have.

Edit/addition: Another phrasing of my question could be "is it possible to create an anyone-can-spend Bech32 public address (as you can do with 3-addresses)?"

Yes, it is. I can make one on testnet if you'd like.

I appreciate the straight answer, thank you!

Then I can drop this one here

script='' #an empty string
bech32(ripemd160(sha256(script))) -> bc1qk3e2yekshkyuzdcx5sfjena3da7rh87t4thq9p

and if you are right (I have no reason left to believe you aren't), no one can redeem the $250 or so worth of BTC sent to it. If it is swept tonight though, things get interesting again

And for the record, I don't think the Bitcoin wiki (linked before) should read "Bech32 pubkey hash or script hash", since we have determined that a script hash won't produce a usable address.

Many thanks! Learned a lot.

And yes please, I would love a demonstration of an anyone-can-spend Bech32 address on the testnet!

[achow101]

And yes please, I would love a demonstration of an anyone-can-spend Bech32 address on the testnet!

A script of 0x51 produces the bech32 testnet address tb1qft5p2uhsdcdc3l2ua4ap5qqfg4pjaqlp250x7us7a8qqhrxrxfsqaqh7jw

Funding transaction: https://blockstream.info/testnet/tx/b8c6bfdd22a7be0ee636491dd10cd12d7a9d78090392d425f6b40391adc9cc2a

Spending transaction: https://blockstream.info/testnet/tx/63437a58b4c12ca8c9f99183a8a09378336f29fe88d4aaec0d7fa0b16b64559f

[BTCW]

And yes please, I would love a demonstration of an anyone-can-spend Bech32 address on the testnet!

A script of 0x51 produces the bech32 testnet address tb1qft5p2uhsdcdc3l2ua4ap5qqfg4pjaqlp250x7us7a8qqhrxrxfsqaqh7jw

Funding transaction: https://blockstream.info/testnet/tx/b8c6bfdd22a7be0ee636491dd10cd12d7a9d78090392d425f6b40391adc9cc2a

Spending transaction: https://blockstream.info/testnet/tx/63437a58b4c12ca8c9f99183a8a09378336f29fe88d4aaec0d7fa0b16b64559f

MUCH OBLIGED! Exactly what I was looking for all along. I am out of merit points to give out, but if I had any left, I'd give them all to this post of yours.

[HCP]

And for the record, I don't think the Bitcoin wiki (linked before) should read "Bech32 pubkey hash or script hash", since we have determined that a script hash won't produce a usable address.

But it will... just not the "script hash" that you are thinking of... refer: https://bitcoincore.org/en/segwit_wallet_dev/#native-pay-to-witness-script-hash-p2wsh

Native Pay-to-Witness-Script-Hash (P2WSH)

• Native P2WSH is a scriptPubKey of 34 bytes. It starts with a OP_0, followed by a canonical push of the scripthash (i.e. 0x0020{32-byte scripthash})
• Same as P2SH-P2WSH, scripthash is SHA256 of the witnessScript.
• When spending a native P2WSH, the scriptSig MUST be empty, and the witness stack format and signature generating rules are same as P2SH-P2WSH (including the requirement of using compressed public key)

NOTE: emphasis added

As per the P2SH-P2WSH docs on that page, the "scripthash" is the SHA256(witnessScript)... it is not double SHA256 nor RIPEMD160(SHA256) etc.

[BTCW]

And for the record, I don't think the Bitcoin wiki (linked before) should read "Bech32 pubkey hash or script hash", since we have determined that a script hash won't produce a usable address.

But it will... just not the "script hash" that you are thinking of... refer: https://bitcoincore.org/en/segwit_wallet_dev/#native-pay-to-witness-script-hash-p2wsh

Native Pay-to-Witness-Script-Hash (P2WSH)

• Native P2WSH is a scriptPubKey of 34 bytes. It starts with a OP_0, followed by a canonical push of the scripthash (i.e. 0x0020{32-byte scripthash})
• Same as P2SH-P2WSH, scripthash is SHA256 of the witnessScript.
• When spending a native P2WSH, the scriptSig MUST be empty, and the witness stack format and signature generating rules are same as P2SH-P2WSH (including the requirement of using compressed public key)

NOTE: emphasis added

As per the P2SH-P2WSH docs on that page, the "scripthash" is the SHA256(witnessScript)... it is not double SHA256 nor RIPEMD160(SHA256) etc.

Loud and clear! Amazing what a little space can do. I would never have interpreted the wiki wrong if it had read "scripthash" (name of variable or function) instead of "script  hash."

I had a question, you guys answered it - I am grateful.

[BTCW]

Had to replicate this on the Bitcoin mainnet - and it worked!

1. Created a "stupid" anyone-can-spend Bech32 address (P2WPK), script= "OP_1":

Code:

>>> import binascii, hashlib, bitcoinutils
>>> from bitcoinutils import bech32
>>> script='51' #opcode OP_1
>>> sha256 = hashlib.sha256(binascii.unhexlify(script)).hexdigest()
>>> bitcoinutils.bech32.encode('bc',0,memoryview(binascii.unhexlify(sha256)).tolist())
'bc1qft5p2uhsdcdc3l2ua4ap5qqfg4pjaqlp250x7us7a8qqhrxrxfsq2gp3gp'

2. Asked a friend to fund it:

Txid: 948e5445aafb999639ed14ea553d4fc437851835eef4662fee2ca78588280408

3. Modified your raw testnet transaction achow101 -tyvm - using Notepad++ into:

Code:

020000000001010804288885a72cee2f66f4ee35188537c44f3d55ea14ed399699fbaa45548e940000000000ffffffff011c2500000000000017a9146b1420fe590900a50e9b7ba697854c44d808e4e58701015100000000

4. Broadcast in Bitcoin Core consolue using "sendrawtransaction"; it was immediately accepted

5. The coins are on their way back, txid: 4f5de655580de1f169de34a660ac982fabf1bf95aed0469755c7b60b108695f4


Pure awesome. Finally, it is interesting that the brainwallet-and-the-like-prying-bots obviously haven't tuned into this (yet?).

Big

[HCP]

I see you were smart and marked it "RBF = False"

I noticed your transaction was still unconfirmed and thought it might be interesting to see if it could be "sniped", given that it is an "anyone can spend" address...

txn-mempool-conflict (code -26)

Sadly, I don't know any miners... so no "double-spend" options available... but it is somewhat reassuring to know the system is working as intended

Finally, it is interesting that the brainwallet-and-the-like-prying-bots obviously haven't tuned into this (yet?).

I think it is mostly because the general use of brainwallets really died out years ago after a lot of coin loss... well before SegWit was a thing. The only SegWit compatible brainwallet I know is https://segwitaddress.org/

Sure, people keep sending coins to well known brainwallet addresses for shits and giggles or "testing" like your BTCLeak friends (abc123 anyone? )... but generally speaking, there really isn't much to be gained from monitoring/sweeping these addresses except the odd bit of dust.

[BTCW]

I see you were smart and marked it "RBF = False"

I noticed your transaction was still unconfirmed and thought it might be interesting to see if it could be "sniped", given that it is an "anyone can spend" address...

txn-mempool-conflict (code -26)

Sadly, I don't know any miners... so no "double-spend" options available... but it is somewhat reassuring to know the system is working as intended

Finally, it is interesting that the brainwallet-and-the-like-prying-bots obviously haven't tuned into this (yet?).

I think it is mostly because the general use of brainwallets really died out years ago after a lot of coin loss... well before SegWit was a thing. The only SegWit compatible brainwallet I know is https://segwitaddress.org/

Sure, people keep sending coins to well known brainwallet addresses for shits and giggles or "testing" like your BTCLeak friends (abc123 anyone? )... but generally speaking, there really isn't much to be gained from monitoring/sweeping these addresses except the odd bit of dust.

Haha! Love the effort. Yeah, when assembling raw transactions in a text editor, it's difficult to get the tx fee right (unless you cheat with an online fee calculator), so I eyeballed it and figured 500 satoshi was reasonable for 10k in total. Maybe went a little low. I think it will sit in the mempool for a day or two.

And yeah, I figured disabling RBF would make it more difficult to hijack or reroute the transaction, even though it is an anyone-can-spend.

Now I kinda want someone to snatch/override my transaction because then I'd learn even more. Give it your best shot! Or two.

[pooya87]

Sadly, I don't know any miners... so no "double-spend" options available... but it is somewhat reassuring to know the system is working as intended

well 9500 satoshi is just too low (it is barely worth 1 buck) so this transaction can be deceiving. a larger amount (not that i'd recommend it) needs to be sent to create the incentive for a double spend and see what happens.
additionally the "bots" may not be watching SegWit witnesses since they are usually old and written pre-SegWit.