nevermind, calculated key is correct it was just the encoding to wif that was not handled correctly

For address 1G4TqNcKTRRuQ3brQSv85Fohf3jQiaGAbL, there are 2 transactions with signatures using the same R:
- 47faedac99c414f103d7f81f409382d19a0e3b98064096f4c446dceadfff689c vout 0
- 01653d5194cde351de1e1c23f3fa5fde25b98cb0068bc5a0c749f8dfccdc4ac1 vout 0

I extract the R, S, Z values as follows:
TX1:
     R: 615e47355ff14f5b00af8943813db16d69c8421ef1145029fd164b29db2c286b
     S: 00861e1477082d4c7443146fcb42741ee6798437a5d44437c7e33d863e730bb426
     Z: c67381a96fcc81ee9d69e252dd112b084871b23a23a8341cc7dbee6d48d8e2c6

TX2:
     R: 615e47355ff14f5b00af8943813db16d69c8421ef1145029fd164b29db2c286b
     S: 008dc69f90f6d94040dc4cd51f297d3d518d04622dcc65f3489804175b681b5b38
     Z: f98bcd3057809e67641b57d51a2d492aa0a49395edbffd58cc819b6e6d844c29

From here I should be able to calculate the private key with the formula
(z2*s1 - z1*s2) * inverse(r*(s2-s1),p) % p

This however results in the raw key 72716422e10951e92990260d905e1006587d162b06fbd890f4105783d88aa26 which translates to the WIF equivalents of 17c3rHrHLSZBnwu3n9JdmjVBPviyGFTxse / 1PWZNyvQmk9GZnivcgboRdWS6me1SkzGje.

This method seems to work for other examples but with this one the resulting key is wrong. What could be the cause?

Signature is valid (try quoting a reply and copy the post message from there)

nice puzzle btw! Will there be any hints regarding the direction?

Ok this is embarrassing, the default windows NTP server was enabed but not working so my PC was indeed more than a minute ahead. This already fixes a large part of the delta. Thanks for all other responses, I can assume all will be a factor for the remaining 40 seconds delay.

I'm still trying to achieve the least as possible, so any other hints or tuning methodes are welcome.

@ETFbitcoin Are the node addresses of miners public? Where to find them? And do they accept any incoming connection as I can imagine a lot of people will want to connect to them for various reasons.

Hi,

I have a Bitcoin core node running (0.16.1) which has 16 outgoing connections (to other fast/stable nodes according to Bitnodes) + approx 8 incoming connections. Full blockchain is synced and all txns are indexed.

Whenever a new block comes in, I can see that the time my node processes it is 2 minutes later than the timestamp on the block. What is the reason of this delay? I can't imagine the propagation will always take this long so is there anything else that might be affecting this?

What are normal delays?

For academic purposes I would like to achieve the least delay possible. What could be options to achieve this? I've read that having more peers would not help but can have an opposite effect?

Note: I've already heard about FIBRE, but I'd like to achieve this without it. Also afaik FIBRE is about compact blocks and I'd also like to receive txns as fast as possible.

kr

@Dogedarkdev Please do not pretend this was only a small glitch. This had real impact. Personally, I lost all mining power for nothing while the hacker earned a lot of coins, which he can keep. If this is the way you will react to this kind of problems when the currency would be big, you'll see some dramatic losses in price.

Project seemed promising, but things like this (and the poor reaction) are bad news. Also other 'simple' problems with the Electrum wallet like the unconfirmed state and the constant connection issues (yes both in the Tor as the non-tor version) are giving away the professionalism and stability yet needs to come.

Were you finally able to solve this or still need help?

Hi Ashkaan,

seems this forum blocked PM's from 'newbies' since today so I couldn't answer your PM anymore. You can message me via Telegram, user @peterb88.

Kr
Peter

Hi BitMaxz,

thanks for your reply. Let e begin with saying this is just an example private key and I did not loose my password. I am just trying to understand how the protection works. The part you quoted is indeed the correct way to decrypt the phrase with the password. My confusion is however how the cracking tools can detect the correct password by only taking the first 16 bytes of the phrase. (Since my assumption is that an encrypted text is compelely garbled and hence being able to detect the password from only 16bytes seems to be a shortcut in the security)

Hi,

From going though the source code of electrum I understand that when you choose password protection (not for the whole wallet), the seed and xprv are encrypted using AES256CBC. In summary, it takes  times a hash of the password and than it encrypts the full string.

Example
"xprv": "xprv9s21ZrQH143K4PFo8hZiVDXKuJeQHrvN6dqvpPMQYDXRnqYMPWQ4GQXYtebCKtF9gu1ses7NNVY 3VCECVgWYpVKziGzTyM3hrfGRKtSsxjF"
Encrypting with password 'test' gives
"xprv": "utyhIJlLf9oIUtc9vqOKS9R6b1KzM+u72Vn7PVoyLFHaRyzJ44zTWLF4RNmUScMHnA6ySJ/USljiOpUjp7lVcb6MR9GfLO1i6VK1iS4souwr/fqkpCHUWH7AXV0APjsa6C/Zpll0LgZ7x0RBv2+SQd54lNpX9XG0NUqbNzeA9tI="

Now, the part that I do not understand is how password crackers (like JTR) can find the password based on only the first 32 out of 128 bytes of this encrypted text. I believe the first 16 bytes are the IV. Are the next 16 bytes separately encrypted or is there some math trick to figure out if the encryption would work?  Any links that explain this would be highly appreciated! I would like to understand the security of the password usage.