You should make your own hardware for pulling random data for your coins. Something like a geiger counter near a radiation source. Now that would be truly the best source for truly random data. (Unless if you distrust the laws of physics  ) I would have, but at the time, I was fresh out of radioactive material. Maybe next time. dismantle a smoke detector |
|
|
|
|
BOOM!
At this rate, my BFL asics will be unprofitable by the end of the year.
|
|
|
|
|
I'm one of the lucky ones who got their orders in early for both FPGAs and ASICs. A very modest operation, but one thing is for sure, when my ASICs become unprofitable (which I expect will be shortly after the new year), I'm totally out of the mining game.
|
|
|
|
Problem for the app developer is that RNG is usually "native" in the sense that it's provided by OS/java runtime/(js implementation) as probably should be (better access to hardware). In java you can't even be sure which native implementation is chosen and as an app developer you'd have to check them for all target platforms somehow. On linux for example you also can't be sure what's hiding behind /dev/urandom.
Which is why the app developer should sprinkle their own magic dust on the numbers, by whatever means. If the app developer absolutely, positively knows the numbers generated have to be absolutely, positively unique and random, then they should not rely on that which they can't control or fully understand/know. It's an assumption to far for something that is so crucial. |
|
|
|
I say they add even more entropy. Why not have us swipe around the screen a bit during a transaction?
I think If I were coding this up, I'd add another layer of entropy on top of the system generated number, just to be sure. A phone's got to have any number of entropy sources... touch screen, signal levels, compass, g-sensor, time, location, light level... |
|
|
|
|
I have to say, I'm somewhat disappointed in the devs not checking to ensure that the random number generator they use, actually works properly and assuming it's all OK, given they know how important the randomness is.
|
|
|
|
|
Oopsie!
I've extracted all mah money... Waiting for update.
|
|
|
|
|
Holy crap that's complicated!
Why's it so complicated!?
|
|
|
|
|
Hmmmm... thinking about this. The chips seem amazing!
|
|
|
|
|
does this mean I'll forever have unconfirmed balance?
|
|
|
|
This kind of devices are often gets hot if plugged in for a long time. Paperclip doesn't. So follow your wishes, don't burn your house down  And think of all those mW wasted, too! |
|
|
|
It's a cool idea so I've gone and ordered one. Things I'd like to see though: NFC Some form of password entry on the device itself (such as my rhythm idea above ) |
|
|
|
|
WL-500g Deluxe (WL-500gx) BCM5365P/BCM5364P 200MHz SoC 802.11g (BCM4306 + BCM2050) 32MB SDR 32bit 4MB 2 x 2.0 (VT6212L)
I'm not sure that'll have the resources to run cgminer :/
But It should at least start. The compiler optimization maybe set for later processors.
|
|
|
|
Received 2x BFL Singles today (ordered June 2012).
Was a bit of a pleasant surprise, as I was only expecting one. (double-checked the order, I paid for two, just forgot)
I wouldn't exactly expect them to screw devs, mods or business owners. Although 14 months can't exactly be called preferential treatment.  I received my two singles a couple weeks back. I'm not a dev, mod, or business owner. I also got my 6 singles, and I'm a nobody who complained about the delay. |
|
|
|
|
a NFS share on start-up could well work. I think you could do that with a start-up script in the admin panel. Mount it top /opt and you should be golden
Though that does mean you'll need another computer on all the time... so why not hook the miner up to that???
|
|
|
|
|
Why's block 250058 stuck on 111 confirmations?
|
|
|
|
|
I got my units, FPGAs and ASICs. Took a fucking long time for both, but I got them. They're not scammers in my eyes, jut inept.
PG, your ridiculous crusade against BFL is getting tiresome, and well, embarrassing.
Who are you trying to save?
|
|
|
|
|
Show Posts
