You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Which goes on to reveal that "Bitcoin private keys should be generated with 256-bits of entropy; unfortunately, affected keys generated with vulnerable BitcoinJS (or dependent projects) often used less entropy than required.... reduces the amount of necessary work anywhere from 32 to 64-bits." due to several potential problems encountered with Random Number Generation in browser-based software used at the time.
What modifications to this project would be required to guess at private keys with this substantially reduced entropy?
Also, what about using btcposbal2csv to only produce a database of non-zero, dormant wallets generated within a targeted time period - e.g 2011-2012 or 2011-2014?
Appreciate your thoughts, thnaks
The text was updated successfully, but these errors were encountered:
Hi Folks,
Given the recent publication
Which goes on to reveal that "Bitcoin private keys should be generated with 256-bits of entropy; unfortunately, affected keys generated with vulnerable BitcoinJS (or dependent projects) often used less entropy than required.... reduces the amount of necessary work anywhere from 32 to 64-bits." due to several potential problems encountered with Random Number Generation in browser-based software used at the time.
What modifications to this project would be required to guess at private keys with this substantially reduced entropy?
Also, what about using btcposbal2csv to only produce a database of non-zero, dormant wallets generated within a targeted time period - e.g 2011-2012 or 2011-2014?
Appreciate your thoughts, thnaks
The text was updated successfully, but these errors were encountered: