address 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE: not understanding weird transaction

[ecdsa123]

here is address : 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE

and output from address above as transaction from 2016-05-09 12:45:  

Code:

https://www.blockchain.com/btc/tx/b5add54960756c58ebabb332c5ef89098d2c3b8f2107b939ec542178e846108b

decoding above transaction as r,s,z:

Code:

r = 0x83fe1c06236449b69a7bee5be422c067d02c4ce3f4fa3756bd92c632f971de06
s = 0x7405249d2aa9184b688f5307006fddc3bd4a7eb89294e3be3438636384d64ce7
z = 0x070239c013e8f40c8c2a0e608ae15a6b1bb4b8fbcab3cff151a6e4e8e05e10b7
 
pubkey = 0x0283FE1C06236449B69A7BEE5BE422C067D02C4CE3F4FA3756BD92C632F971DE06

so : someone has cracked it : 

nonce used for this transaction is as k:

k= 0x70239C013E8F40C8C2A0E608AE15A6B23D4A09295BE678B21A5F1DCEAE1F634


now : compare z (message hash) with nonce k :
z = [b]0x070239c013e8f40c8c2a0e608ae15a6b[/b]1bb4b8fbcab3cff151a6e4e8e05e10b7
k=  [b]0x070239C013E8F40C8C2A0E608AE15A6B[/b]23D4A09295BE678B21A5F1DCEAE1F634

as we see part of z is the same as integer value of used nonce k.

Question 1: How and why it has been happen?

[1714320215]

1714320215

[1714320215]

1714320215

[1714320215]

1714320215

[1714320215]

1714320215

[pooya87]

so : someone has cracked it :
Question 1: How and why it has been happen?

This is a very old puzzle where someone created a brainwallet using the phrase "bitcoin is awesome" and the private key of this address has been known for the past 10 years. If by "cracked it" you mean solved the brainwallet puzzle, then yes.
As for the Question, in later years others may have tried to have some fun with the existing puzzle by sending coins there and/or spend the coins in this known address with weird nonce values.

[ecdsa123]

yes, but I'm asking about not private key, but nonce used in transaction.
this is weird.

that nonce k is the same as message hash in first 16 bytes

[pooya87]

yes, but I'm asking about not private key, but nonce used in transaction.
this is weird.

that nonce k is the same as message hash in first 16 bytes

It could be a lot of things, as I said it could be someone just having fun trolling others watching this puzzle key or it could be a broken code that someone was testing using this key maybe someone watching the key to steal the coins sent to it.

When generating k deterministically using RFC6979 you use the message digest (z) too. A broken implementation could have messed up and after computing the final HMAC copied the result in the second half of an output that had the original digest in its first half.

[ecdsa123]

is any way for check that:

"When generating k deterministically using RFC6979 you use the message digest (z) too. A broken implementation could have messed up and after computing the final HMAC copied the result in the second half of an output that had the original digest in its first half"

?

[pooya87]

The only way to check it is to find out who sent these and ask them how or why they did it like that. Everything else is just guesswork.

[NotATether]

is any way for check that:

"When generating k deterministically using RFC6979 you use the message digest (z) too. A broken implementation could have messed up and after computing the final HMAC copied the result in the second half of an output that had the original digest in its first half"

?

Depends heavily on the wallet software, so if you know which one sent the transaction, you can just go through the source code, or assembly if it's proprietary, and study the nonce implementation used there.

[ecdsa123]

I have genereate almost about 100 task for find similiar result under testing (generate by my self with knowing private key and nonce)
I do not know how he did it.

any help?

[ymgve2]

This is someone's broken deterministic nonce generation.

Small hint: What's the SHA256 hash of "bitcoin is awesome" which is the private key of the transaction?

[ecdsa123]

I know exactly private key and nonce used in this transaction

I'm just trying understand is that nonce and message hash has the same value as first 32 bytes was did by hand or problem with software:)

[ymgve2]

You didn't understand.

Where do you think the last 16 bytes of the nonce comes from?

[ecdsa123]

z is message hash from transaction
k is integer of nonce used in transaction

z = 0x070239c013e8f40c8c2a0e608ae15a6b1bb4b8fbcab3cff151a6e4e8e05e10b7
k=  0x070239C013E8F40C8C2A0E608AE15A6B23D4A09295BE678B21A5F1DCEAE1F634


the same part MSB of k and MSB of z are the same

0x070239C013E8F40C8C2A0E608AE15A6B == 0x070239c013e8f40c8c2a0e608ae15a6b
MSB of nonce                                            == MSB of message hash (z)

[ymgve2]

privkey is 23d4a09295be678b21a5f1dceae1f634a69c1b41775f680ebf8165266471401b

second part of nonce is 23d4a09295be678b21a5f1dceae1f634

[ecdsa123]

privkey is 23d4a09295be678b21a5f1dceae1f634a69c1b41775f680ebf8165266471401b

second part of nonce is 23d4a09295be678b21a5f1dceae1f634

thanks


so do you think it is by hand generate or "problem with hmac"?

[ymgve2]

It seems like some homebrew way of creating a (bad) deterministic nonce. It's too simple and clean to be just a coding mistake.

And it's bad because reusing part of the unhashed private keys and z means the nonce can now be expressed purely as a linear function of other parts of the signing process.

[ecdsa123]

is any way to check by algorithm that the part of msb of message hash is a part for nonce?

I tried analyze and have a problem with that