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?
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