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
Topic: t (Read 256 times)
privkey is 23d4a09295be678b21a5f1dceae1f634a69c1b41775f680ebf8165266471401b
second part of nonce is 23d4a09295be678b21a5f1dceae1f634
second part of nonce is 23d4a09295be678b21a5f1dceae1f634
thanks
so do you think it is by hand generate or "problem with hmac"?
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)
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)
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.
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.
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"
?
"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.
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.this is weird.
that nonce k is the same as message hash in first 16 bytes
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.
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. Question 1: How and why it has been happen?
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.
Jump to: