A breakable P2SH address - Bitcoin testnet inside

Tepan

jr. member

Activity: 79

Merit: 1

Quote from: BTCW on August 06, 2020, 06:49:14 AM

Quote from: BTCW on August 04, 2020, 02:05:06 PM

Alright, so show me your kung fu BrewMaster!

I threw together a new locking script (only difference is pushing different gibberish 8-byte strings twice, to get a unique address)

Code:

OP_SIZE
OP_SWAP
OP_SIZE
OP_NIP
8 0xd7a41d9c57b451da
OP_ROT
OP_ROT
OP_EQUAL
OP_ROT
OP_DROP
OP_SWAP
OP_DROP
OP_1
8 0x99b51d4455b651db
OP_DROP
OP_EQUAL

and sent 0.1 tBCT to it.

(The to me anonymous person who took it the first time suddenly returned it a while ago, tyvm.)

If you can spend it with a complete redeem script SHORTER than

"<1-byte size padding>025151<32-byte locking script>"

I will be impressed! Show me. (Just snatching it with the above code is "meh".)

OK, full disclosure, I couldn't wait more than two days, so I took it back. In your name, BrewMaster, so to speak! The unlocking code I used was

Code:

4 0x42726577 #ASCII to hex for "Brew"
6 0x4d6173746572 #ASCII to hex for "Master"

And as you had pointed out, this proves that my not-very-awesome script doesn't really compare input lengths as I thought it did, since 0x04 is obviously not equal to 0x06 - you were right all along. (However, I was never able to get anything that included changes to or completely omitting the locking code to work.)

Tx id: 42f6d6ba8317afcc7b6e54d6cc09839f7cc224ca9bf26c0c026432b1fa9c3f44

Raw rx:

Code:

010000000186683e20bde5167c89deb085f5ba00ac6f00b9592f5e21dde674df2f5cbcaf94010000002d0442726577064d617374657220827c827708d7a41d9c57b451da7b7b877b757c75510899b51d4455b651db7587ffffffff01b08e98000000000017a914628cde58e1bcd42efb72b1821ec9fdf49e0f1d498700000000

This was fun and instructive. Now on to new adventures.

Suggestions, anyone?

can you target the public address on P2SH ?
because i have the public key only, in that one addresses.

BTCW

copper member

Activity: 193

Merit: 255

Click "+Merit" top-right corner

Quote from: BTCW on August 04, 2020, 02:05:06 PM

Alright, so show me your kung fu BrewMaster!

I threw together a new locking script (only difference is pushing different gibberish 8-byte strings twice, to get a unique address)

Code:

OP_SIZE
OP_SWAP
OP_SIZE
OP_NIP
8 0xd7a41d9c57b451da
OP_ROT
OP_ROT
OP_EQUAL
OP_ROT
OP_DROP
OP_SWAP
OP_DROP
OP_1
8 0x99b51d4455b651db
OP_DROP
OP_EQUAL

and sent 0.1 tBCT to it.

(The to me anonymous person who took it the first time suddenly returned it a while ago, tyvm.)

If you can spend it with a complete redeem script SHORTER than

"<1-byte size padding>025151<32-byte locking script>"

I will be impressed! Show me. (Just snatching it with the above code is "meh".)

OK, full disclosure, I couldn't wait more than two days, so I took it back. In your name, BrewMaster, so to speak! The unlocking code I used was

Code:

4 0x42726577 #ASCII to hex for "Brew"
6 0x4d6173746572 #ASCII to hex for "Master"

And as you had pointed out, this proves that my not-very-awesome script doesn't really compare input lengths as I thought it did, since 0x04 is obviously not equal to 0x06 - you were right all along. (However, I was never able to get anything that included changes to or completely omitting the locking code to work.)

Tx id: 42f6d6ba8317afcc7b6e54d6cc09839f7cc224ca9bf26c0c026432b1fa9c3f44

Raw rx:

Code:

010000000186683e20bde5167c89deb085f5ba00ac6f00b9592f5e21dde674df2f5cbcaf94010000002d0442726577064d617374657220827c827708d7a41d9c57b451da7b7b877b757c75510899b51d4455b651db7587ffffffff01b08e98000000000017a914628cde58e1bcd42efb72b1821ec9fdf49e0f1d498700000000

This was fun and instructive. Now on to new adventures.

Suggestions, anyone?

A-Bolt

legendary

Activity: 2317

Merit: 2318

Quote from: BTCW on August 04, 2020, 08:40:20 PM

Wowzers!! Looks like someone cracked my challenge 2 (but is for some reason not interested in writing about it here?!).

Here I am. I created multisig address in a different way:

Code:

importprivkey cNvV73g3NgnSRtX4jfENnDBgQNaVqg7YYYuNpS8SBm41UuZxmrAi sig1 false
importprivkey cPehe5iiYgmNCKTVyiytGVh3g1pyQMQDSSidaKJcTVPt8gm1bcgD sig2 false

addmultisigaddress 2 "[\"mqNsE5yRBcRhfkKiFZqPxRfS6B7V2hqUtT\",\"n3iBcnhmJ7oLk4gKjfJiFCk3hSb4LZJe3J\"]"

rescan

Then I made spent tx in Bitcoin Core GUI.

BTCW

copper member

Activity: 193

Merit: 255

Click "+Merit" top-right corner

Challenge 2 - we have a winner!

Wowzers!! Looks like someone cracked my challenge 2 (but is for some reason not interested in writing about it here?!).

This transaction is proof of sweeping 2MsucLKM489owxv6emXfCVRCZ3UFb7MnXCR

I suppose it's my job to disclose how it was constructed, and thus how it can be robbed.

To increase difficulty I decide to go with a multisig address (2-of-2 to be exact).

In order to create a multisig address (I will now mention HD and deterministic wallets, BIP32, xpriv, xpub and such terms here) you need several private keys. In this example, two private keys to be precise. What is a private key? Well, it is a random (HOPEFULLY) 256-bit/32-byte number, which is often written out as 64 character hexadecimal strings.

Remember my fake unlocking script in the first example? This:

Code:

32 0x2803d055a4a133bde555a39d37762c8354b6f7418817c5c4b516cf413b280209
32 0x3dbb8323f94bf9acd13a5f92e0d0a7e87f34e31b09a866fdc80437a57e24a114

So I took these pseudorandom numbers and converted them to Bitcoin-testnet private key (using my favorite tool)

This gave:

Key 1 of 2

Code:

Private key hex: 2803d055a4a133bde555a39d37762c8354b6f7418817c5c4b516cf413b280209
Compression: YES*
Testnet private key WIF: cNvV73g3NgnSRtX4jfENnDBgQNaVqg7YYYuNpS8SBm41UuZxmrAi
Testnet public key: 02fcc55dca84d81390bf05fe301c49771e4de96039acd54d1ab2fe49ce36bc041e
Testnet public address: mqNsE5yRBcRhfkKiFZqPxRfS6B7V2hqUtT

Key 2 of 2

Code:

Private key hex: 3dbb8323f94bf9acd13a5f92e0d0a7e87f34e31b09a866fdc80437a57e24a114
Compression: YES*
Testnet private key WIF :cPehe5iiYgmNCKTVyiytGVh3g1pyQMQDSSidaKJcTVPt8gm1bcgD
Testnet public key: 031033d9c6d66b3222df19cc5dfb7022b314bf035115f7cd76f72934863adebf69
Testnet public address: n3iBcnhmJ7oLk4gKjfJiFCk3hSb4LZJe3J

Great. A short comment on compressed vs uncompressed keys: Whenever I can, I always choose compressed; so should you. I then decided to throw them together in Bitcoin Core (google says it's impossible in Electrum, but I'm working on a work-around for it, almost done, watch this space).

In Bitcoin Core (remember to run in testnet mode) console, you first need to get hold your redeem script, and it can be done with

Code:

createmultisig 2 '["02fcc55dca84d81390bf05fe301c49771e4de96039acd54d1ab2fe49ce36bc041e","031033d9c6d66b3222df19cc5dfb7022b314bf035115f7cd76f72934863adebf69"]'

As can be seen, we are using two public keys and NOT private keys or public adddresses; very common mistakes), and it spits out

Code:

{
  "address": "2MsucLKM489owxv6emXfCVRCZ3UFb7MnXCR",
  "redeemScript": "522102fcc55dca84d81390bf05fe301c49771e4de96039acd54d1ab2fe49ce36bc041e21031033d9c6d66b3222df19cc5dfb7022b314bf035115f7cd76f72934863adebf6952ae",
}

There is our redeem script, that we will use in the second step, still in the console (here we feed it with everything: public addresses, private keys, redeem script)

Code:

importmulti '[{ "scriptPubKey": { "address": "2MsucLKM489owxv6emXfCVRCZ3UFb7MnXCR" }, "timestamp":"now", "keys": [ "cNvV73g3NgnSRtX4jfENnDBgQNaVqg7YYYuNpS8SBm41UuZxmrAi","cPehe5iiYgmNCKTVyiytGVh3g1pyQMQDSSidaKJcTVPt8gm1bcgD" ], "redeemscript": "522102fcc55dca84d81390bf05fe301c49771e4de96039acd54d1ab2fe49ce36bc041e21031033d9c6d66b3222df19cc5dfb7022b314bf035115f7cd76f72934863adebf6952ae"}]' '{"rescan": false}'

If done right it should reply with a "success!" message.

Now the address is in our wallet, but it is watch-only, since we haven't fed it with the private keys (I have no idea why the last command doesn't associate the provided private keys), so - still in console:

Code:

importprivkey cNvV73g3NgnSRtX4jfENnDBgQNaVqg7YYYuNpS8SBm41UuZxmrAi key1 false
importprivkey cPehe5iiYgmNCKTVyiytGVh3g1pyQMQDSSidaKJcTVPt8gm1bcgD key2 false

Then, for the finale, issue:

Code:

rescanblockchain

It will take several minutes of a fast computer with an SSD. Grab a coffee while waiting.

Done! You now have full control over 2MsucLKM489owxv6emXfCVRCZ3UFb7MnXCR and can spend from it like any other address in your wallet.

Prolog: I figured recycling two already mentioned 32-byte strings, using them as private keys, and joining them together in a multisig address was fun.

We good?

BTCW

copper member

Activity: 193

Merit: 255

Click "+Merit" top-right corner

Quote from: BrewMaster on August 04, 2020, 10:02:58 AM

Quote from: BTCW on August 04, 2020, 09:32:29 AM

1) Yeah, I know about standardness. I "only" have access to Bitcoin Core, Electrum, and the online push raw tx tools, and while Blockcypher seems to be the most relaxed of them, not even that one allows non-push codes in the unlocking script. I am not a miner (on the mainnet, duh); if I were, we wouldn't sit here and have this conversation, I think

(Satoshi's first versions allowed all opcodes in the unlocking script, but that's pretty crazy because you can use that to drain computational power of all nodes)

you can always mine in regtest mode. the difficulty is too low that you can mine thousands of blocks within seconds and it won't go up either.
but for now here is a test case that has OP_CHECKSIG inside scriptsig:
https://github.com/bitcoin/bitcoin/blob/b53af72b8276e8a23915d38fe459889cccb56f50/src/test/data/tx_valid.json#L169

Quote

2) Gotcha. Thanks for pointing that out. Are you saying a complete redeem (unlocking+locking) script of "030151" would have unlocked my first UTXO, first address example in this thread? If so, cool. Gotta try out.

the data part could be anything but you still need at least 2 items (since OP codes like NIP and SWAP need 2 items) and they could be anything even un-equal values since it seems like your redeemscript is dropping the comparison result from the stack anyways so it won't matter.
also the redeem script itself must be there too.

by the way 030151 is an invalid script because it has 2 bytes instead of 3 (0x03 + 0x0151)

Oops, byte padding above is of course 02 and not 03, apart from the little fact that 01 in there makes no sense; I meant "025151" (Note to self: preview and proofread before posting)

Alright, so show me your kung fu BrewMaster!

I threw together a new locking script (only difference is pushing different gibberish 8-byte strings twice, to get a unique address)

Code:

OP_SIZE
OP_SWAP
OP_SIZE
OP_NIP
8 0xd7a41d9c57b451da
OP_ROT
OP_ROT
OP_EQUAL
OP_ROT
OP_DROP
OP_SWAP
OP_DROP
OP_1
8 0x99b51d4455b651db
OP_DROP
OP_EQUAL

and sent 0.1 tBCT to it.

(The to me anonymous person who took it the first time suddenly returned it a while ago, tyvm.)

If you can spend it with a complete redeem script SHORTER than

"<1-byte size padding>025151<32-byte locking script>"

I will be impressed! Show me. (Just snatching it with the above code is "meh".)

Also everyone - challenge 2 is still on!
(It is admittedly harder, but by no means unsolvable, all data needed to break it has been mentioned in this thread.)

BrewMaster

legendary

Activity: 2128

Merit: 1293

There is trouble abrewing

Quote from: BTCW on August 04, 2020, 09:32:29 AM

1) Yeah, I know about standardness. I "only" have access to Bitcoin Core, Electrum, and the online push raw tx tools, and while Blockcypher seems to be the most relaxed of them, not even that one allows non-push codes in the unlocking script. I am not a miner (on the mainnet, duh); if I were, we wouldn't sit here and have this conversation, I think

(Satoshi's first versions allowed all opcodes in the unlocking script, but that's pretty crazy because you can use that to drain computational power of all nodes)

you can always mine in regtest mode. the difficulty is too low that you can mine thousands of blocks within seconds and it won't go up either.
but for now here is a test case that has OP_CHECKSIG inside scriptsig:
https://github.com/bitcoin/bitcoin/blob/b53af72b8276e8a23915d38fe459889cccb56f50/src/test/data/tx_valid.json#L169

Quote

2) Gotcha. Thanks for pointing that out. Are you saying a complete redeem (unlocking+locking) script of "030151" would have unlocked my first UTXO, first address example in this thread? If so, cool. Gotta try out.

the data part could be anything but you still need at least 2 items (since OP codes like NIP and SWAP need 2 items) and they could be anything even un-equal values since it seems like your redeemscript is dropping the comparison result from the stack anyways so it won't matter.
also the redeem script itself must be there too.

by the way 030151 is an invalid script because it has 2 bytes instead of 3 (0x03 + 0x0151)

BTCW

copper member

Activity: 193

Merit: 255

Click "+Merit" top-right corner

Quote from: BrewMaster on August 04, 2020, 09:24:51 AM

Quote from: BTCW on August 04, 2020, 09:14:22 AM

1) Correct me if I'm wrong but unlocking scripts must, to the best of knowledge, be "push only", and if you include any other opcode you will get "64: scriptsig-not-pushonly" (I've hit this wall a number of times)

that is only if you want it to be standard.
unfortunately 90% of the things we read on forums, SE, documentation,... that say "must be" are talking about standard rules.
SCRIPT_VERIFY_SIGPUSHONLY flag is only added to standard rules and doesn't exist during block verification.

to test this you have to mine the block yourself!

Quote

2) If you fiddle around with the locking script, its hash will change which will invalidate the transaction?

the transaction hash will change but it won't make the transaction invalid. because the transaction you are verifying is not using its own hash.

that is what malleability is. fiddling around with the transaction scripts to change its hash and cause troubles. most of the cases are already fixed and can no longer happen. they are explained in BIP-62.
for example OP_CHECKMULTISIG(VERIFY) OPs pop an extra item from the stack and is ignored so it could be anything. an attacker could easily change it to any other push and create any number of still valid transactions each with a different hash. with SegWit softfork this can no longer happen. the flag is SCRIPT_VERIFY_NULLDUMMY which you can see is used during verification too.

i should also mention that all bitcoin core nodes reject all non-standard transactions so malleability is not a problem because it is practically impossible to perform.

1) Yeah, I know about standardness. I "only" have access to Bitcoin Core, Electrum, and the online push raw tx tools, and while Blockcypher seems to be the most relaxed of them, not even that one allows non-push codes in the unlocking script. I am not a miner (on the mainnet, duh); if I were, we wouldn't sit here and have this conversation, I think

(Satoshi's first versions allowed all opcodes in the unlocking script, but that's pretty crazy because you can use that to drain computational power of all nodes)

2) Gotcha. Thanks for pointing that out. Are you saying a complete redeem (unlocking+locking) script of "030151" would have unlocked my first UTXO, first address example in this thread? If so, cool. Gotta try out.

BrewMaster

legendary

Activity: 2128

Merit: 1293

There is trouble abrewing

Quote from: BTCW on August 04, 2020, 09:14:22 AM

1) Correct me if I'm wrong but unlocking scripts must, to the best of knowledge, be "push only", and if you include any other opcode you will get "64: scriptsig-not-pushonly" (I've hit this wall a number of times)

that is only if you want it to be standard.
unfortunately 90% of the things we read on forums, SE, documentation,... that say "must be" are talking about standard rules.
SCRIPT_VERIFY_SIGPUSHONLY flag is only added to standard rules and doesn't exist during block verification.

to test this you have to mine the block yourself!

Quote

2) If you fiddle around with the locking script, its hash will change which will invalidate the transaction?

the transaction hash will change but it won't make the transaction invalid. because the transaction you are verifying is not using its own hash.

that is what malleability is. fiddling around with the transaction scripts to change its hash and cause troubles. most of the cases are already fixed and can no longer happen. they are explained in BIP-62.
for example OP_CHECKMULTISIG(VERIFY) OPs pop an extra item from the stack and is ignored so it could be anything. an attacker could easily change it to any other push and create any number of still valid transactions each with a different hash. with SegWit softfork this can no longer happen. the flag is SCRIPT_VERIFY_NULLDUMMY which you can see is used during verification too.

i should also mention that all bitcoin core nodes reject all non-standard transactions so malleability is not a problem because it is practically impossible to perform.

BTCW

copper member

Activity: 193

Merit: 255

Click "+Merit" top-right corner

Quote from: BrewMaster on August 04, 2020, 09:03:11 AM

Quote from: BTCW on August 04, 2020, 04:37:56 AM

...
This isn't correct. I designed the locking script so it requires exactly two pushes of equal string length. An empty unlocking script will fail. Also, "lots of OP codes" will fail too.

it is not "string" length despite what the wiki says, it is byte length and what i meant was that you can change the 2 initial data that are being pushed to the stack to be literary anything. then you can also add some other garbage code there for example the second thing you posted can be modified to this that even has an OP_CHECKSIG inside and it still passes:

Code:

OP_5 0x03ffffff OP_CHECKSIG OP_NOT OP_1 OP_1

and it still has nothing to do with breaking the redeem script Tongue

Hm, two questions:

1) Correct me if I'm wrong but unlocking scripts must, to the best of knowledge, be "push only", and if you include any other opcode you will get "64: scriptsig-not-pushonly" (I've hit this wall a number of times)

2) If you fiddle around with the locking script, its hash will change which will invalidate the transaction?

BrewMaster

legendary

Activity: 2128

Merit: 1293

There is trouble abrewing

Quote from: BTCW on August 04, 2020, 04:37:56 AM

...
This isn't correct. I designed the locking script so it requires exactly two pushes of equal string length. An empty unlocking script will fail. Also, "lots of OP codes" will fail too.

it is not "string" length despite what the wiki says, it is byte length and what i meant was that you can change the 2 initial data that are being pushed to the stack to be literary anything. then you can also add some other garbage code there for example the second thing you posted can be modified to this that even has an OP_CHECKSIG inside and it still passes:

Code:

OP_5 0x03ffffff OP_CHECKSIG OP_NOT OP_1 OP_1

and it still has nothing to do with breaking the redeem script Tongue

BTCW

copper member

Activity: 193

Merit: 255

Click "+Merit" top-right corner

A new challenge

You asked for it, and you will have it. This time around:

Includes signatures
Not an anyone-can-spend address

Check out 2MsucLKM489owxv6emXfCVRCZ3UFb7MnXCR

It has been funded once with 0.1 tBTC, spent from once, and is funded again with 0.1 tBTC

ALL INFORMATION NEEDED TO BREAK IT IS IN THIS THREAD

I will prove it by writing out the solution here, if no one has swept it within a day or so. I someone sweeps it sooner (and doesn't write anything here), I will publish the solution asap.

Go!

BTCW

copper member

Activity: 193

Merit: 255

Click "+Merit" top-right corner

Quote from: BASE16 on August 04, 2020, 07:16:17 AM

A script can be anything.
Anything is quite a broad thing, since it includes everything.

Here is a small 1 BTC challenge for you to solve: https://bitaps.com/mnemonic/challenge

Those aren't test coins

Nice bounty program. That address was funded six weeks or so ago, so I guess I wasn't in mind then. By the way, a point of the elliptic curve can be almost anything (well, within the secp256k1 parameters, an insanely large but not infinite space), but a script cannot "include everything", since it is a program that must run and evaluate to "TRUE".

BASE16

member

Activity: 180

Merit: 38

A script can be anything.
Anything is quite a broad thing, since it includes everything.

Here is a small 1 BTC challenge for you to solve: https://bitaps.com/mnemonic/challenge

Those aren't test coins

BTCW

copper member

Activity: 193

Merit: 255

Click "+Merit" top-right corner

Quote from: TheArchaeologist on August 04, 2020, 04:36:44 AM

Quote from: BTCW on August 04, 2020, 04:19:32 AM

I promise to be more pedagogical in coming write-ups (if there will be any). In this case, the challenge could have been "using different signatures" and the simplest answer would be "OP_1 OP_1".

Maybe you should try to understand these thing a bit better yourself before trying to educate others. There are none, 0, zilch signatures involved in your "challenge".

You quoted me faster than I could edit my post. I shouldn't have used the word "signatures", it is misleading. As already said, this is an anyone-can-spend as there is no signing going on anywhere.

Again, all I did was to try and create a transaction that looked like it required signatures.

I hear you loud and clear. You don't like write-ups of this kind. Will refrain from posting further.

BTCW

copper member

Activity: 193

Merit: 255

Click "+Merit" top-right corner

Quote from: BrewMaster on August 04, 2020, 04:25:57 AM

Quote from: BTCW on August 04, 2020, 04:13:59 AM

you found one case of transaction malleability.
it doesn't matter what you place before your redeem script, it can even be empty or it can contain lots of OP codes, it still evaluates the same.
by the way it has nothing to do with "breaking the redeem script".

This isn't correct. I designed the locking script so it requires exactly two pushes of equal string length. An empty unlocking script will fail. Also, "lots of OP codes" will fail too.

TheArchaeologist

sr. member

Activity: 310

Merit: 727

---------> 1231006505

Quote from: BTCW on August 04, 2020, 04:19:32 AM

I promise to be more pedagogical in coming write-ups (if there will be any). In this case, the challenge could have been "using different signatures" and the simplest answer would be "OP_1 OP_1".

Maybe you should try to understand these thing a bit better yourself before trying to educate others. There are none, 0, zilch signatures involved in your "challenge".

BrewMaster

legendary

Activity: 2128

Merit: 1293

There is trouble abrewing

Quote from: BTCW on August 04, 2020, 04:13:59 AM

I tried to disguise an anyone-can-spend P2SH address as well as I could so that a spending on the blockchain (the first) would contain three 32-byte strings as the sigscript. That was all.

well the moment you posted the link to that address here (the first line of this topic) that disguise stopped working.

Quote

After someone else redeemed the coins, I later showed that my much shorter unlocking code "OP_1 OP_1" can be used, tx here.

you found one case of transaction malleability.
it doesn't matter what you place before your redeem script, it can even be empty or it can contain lots of OP codes, it still evaluates the same.
by the way it has nothing to do with "breaking the redeem script".

Quote

I'm honestly not convinced someone would have noticed anything if I hadn't written about it here.

you are probably right but only because it is "testnet" and it has no value. doing the same on mainnet would surely lead to an immediate double spending of the same coins by multiple transactions, more if the value is high (like 0.1BTC which is worth $1100+).

Quote

I'm not sure I follow your reasoning around the word "breaking". R- and S-reuse, for example, the good old classic bad (static nonce) signature that leads to private key leakage, is that "breaking" or "f-ck obvious"?

well there is no signature involved anywhere in your transaction as there is no OP_CHECK(MULTI)SIG(VERIFY) OP codes anywhere in it. we are talking about an arbitrary script that anyone can spend and is also revealed already.

BTCW

copper member

Activity: 193

Merit: 255

Click "+Merit" top-right corner

Quote from: TheArchaeologist on August 04, 2020, 01:21:32 AM

I am not sure what you tried to accomplish with this "breakable P2SH address" challenge. That would imply you could either reverse the hash so the input of the hash would become apparent or bruteforce the script content so it would hash to the same value and in turn to the same address of the "challenge".

Instead you created a unguessable complicated anyone-can-spend script, and since you know what the script was you used it to unlock it in a testnet transaction. Then the solution to your "challenge" is to simply copy and paste the unlocking script from the previous transaction to re-use. So the content of the script itself is completely irrelevant, this would work for any script that is made up of anyone-can-spend content.

All in all there was nothing to break in your "challenge" in the first place.

I promise to be more pedagogical in coming write-ups (if there will be any). In this case, the challenge could have been "using different signatures" and the simplest answer would be "OP_1 OP_1".

BTCW

copper member

Activity: 193

Merit: 255

Click "+Merit" top-right corner

Quote from: BrewMaster on August 04, 2020, 12:21:15 AM

Quote from: BTCW on August 03, 2020, 12:58:16 PM

It is easier than you think to break it. And someone just did:

i don't know if you don't know the meaning of the word "break" or just misusing it but this is not what "breaking" means. breaking would be if and only if the only thing that was revealed were the hash of the script and nothing else.
as i said there is absolutely no way of breaking it when it is only the hash. but when you have already revealed the script here (which anyone can spend) all it takes is a copy and paste of it into a new transaction spending the new output(s).

I tried to disguise an anyone-can-spend P2SH address as well as I could so that a spending on the blockchain (the first) would contain three 32-byte strings as the sigscript. That was all.

After someone else redeemed the coins, I later showed that my much shorter unlocking code "OP_1 OP_1" can be used, tx here.

I'm honestly not convinced someone would have noticed anything if I hadn't written about it here. In fact, thus is very testable: I'll make another similar but not identical "crazy" script, fund it, spend from it, fund it again, but write nothing about it for several days. And see what happens.

I'm not sure I follow your reasoning around the word "breaking". R- and S-reuse, for example, the good old classic bad (static nonce) signature that leads to private key leakage, is that "breaking" or "f-ck obvious"?

TheArchaeologist

sr. member

Activity: 310

Merit: 727

---------> 1231006505

I am not sure what you tried to accomplish with this "breakable P2SH address" challenge. That would imply you could either reverse the hash so the input of the hash would become apparent or bruteforce the script content so it would hash to the same value and in turn to the same address of the "challenge".

Instead you created a unguessable complicated anyone-can-spend script, and since you know what the script was you used it to unlock it in a testnet transaction. Then the solution to your "challenge" is to simply copy and paste the unlocking script from the previous transaction to re-use. So the content of the script itself is completely irrelevant, this would work for any script that is made up of anyone-can-spend content.

All in all there was nothing to break in your "challenge" in the first place.

Topic: A breakable P2SH address - Bitcoin testnet inside (Read 646 times)