If that were true, he wouldn't have built something so perfect for abuse.
HN user
jwilkins
He now retracts, says it was poorly worded: https://twitter.com/iang_fc/status/727071298325618689
/dev/urandom while entropy available is low:
$ rngtest -c 200000 -b 2000 < /dev/urandom
.....
rngtest: bits received from input: 4000000032
rngtest: FIPS 140-2 successes: 199848
rngtest: FIPS 140-2 failures: 152
rngtest: FIPS 140-2(2001-10-10) Monobit: 24
rngtest: FIPS 140-2(2001-10-10) Poker: 15
rngtest: FIPS 140-2(2001-10-10) Runs: 60
rngtest: FIPS 140-2(2001-10-10) Long run: 54
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=3.782; avg=63.752; max=82.928)Mibits/s
rngtest: FIPS tests speed: (min=4.559; avg=158.909; max=194.627)Mibits/s
rngtest: Program run time: 83882495 microseconds
It gets much worse.Unpredictable and unbiased source of bytes, even on server machines and virtualized hardware at boot time.
I hope that this was offered as an example of the sorts of broken thinking that justifies this sort of backdoor that eventually leaks/is discovered by others.
1. Key based backdoors are as good as it gets, but in order to be useful to most large entities, they have to be at least somewhat exposed internally, making them prime targets for leakers. 2. Hackers routinely take over routers. Ask Juniper. 3. Telcos get hacked. 4. Hackers are curious fuckers who are interested in the most obscure things. 5. Also the most impressive boxes, someone will either find a way to emulate it or someone from the team will find it impossible not to build one at home on the weekend 6. See wireshark also the automated protocol dissector research 7. Vendors are owned, hackers get early access too.
One thing I can add from my analysis is that there aren't seperate counters for files/teams/etc. there's only one. So if a given id is used by a team, it won't be used as a file id.
Interestingly, I put the same bug in at HackerOne 9 months ago. It was closed as not applicable. So they had at least two independent reports of the same bug and failed to understand it, acknowledge it and then fix it.
Way to go slack.
If you have any critical data passing through slack, when you get owned, you won't be able to say say it wasn't entirely preventable.
DJB's nacl or libgpgme.
Why does the penny transaction have to confirm in 10 mins? Currently, and for at least a couple of years, you will likely still be able to send 0 fee transactions. The time for them to appear in a block will increase however.
Have you heard of Lightning (https://lightning.network)?
Core has been moving away from failed experiments like unconfirmed transactions. (How that wasn't an obviously flawed idea in the first place is beyond me, but hey, might as well get the data..)
No one in core is saying that growth is a bad thing and must be avoided, the key point that has been repeated is that the approach you and Gavin took with XT was not a good one. It has been poorly thought out from the get go. The initial proposal contended that we had to go to 20MB or we were doomed, remember that?
Bitcoin needs a steady hand at the wheel. Wladimir and co are putting out a solid amount of code with remarkably little disruption.
Your statement re: orchid is a little misleading. You might be a maintainer, but https://github.com/subgraph/Orchid/commits/develop shows that your contributions are minor. https://github.com/subgraph/Orchid/graphs/contributors
Why do you continue to cause this degree of public spectacle and unnecessary drama?
yeah, not so much: http://motherboard.vice.com/read/wire-built-by-ex-skype-empl...
FWIW, direct link to cached version of gopresto page: http://webcache.googleusercontent.com/search?q=cache:K6ckHm8...
here's the link the gopresto dump, from above
http://rghost.net/private/58630972/989ff79551ac37019982d8117...
Missed cs_dump.txt though.
any reason you didn't use https://github.com/jimhester/per-directory-history
DRC is hardly a conflict free region, or if it is right this moment, it is only because the genocide was so far reaching that there is no one left causing sufficient disturbance to meet whatever bar they've set.
http://en.wikipedia.org/wiki/Democratic_Republic_of_the_Cong...
From the article: - 45,000 people were dying daily as of 2009 - estimates on deaths due to the most recent conflict (deadliest since WWII) were 5,400,000 (though that number is in dispute, no one seems to be standing firmly behind another statistic). - 400,000 women are raped yearly (2011 statistic)
WTF.
or cli via https://github.com/dcadenas/gmail_sender
create ~/.gmail and the post's example is:
gmail -t dbieber@princeton.edu -s "Automate your life: sending emails" -c "Why'd the elephant sit on the marshmallow?"
plus you can have a default receiver and sha256deep -rl / | gmail
also useful is filtering via https://github.com/antifuchs/gmail-brittaCAPTCHA comes from "Completely Automated Public Turing test to tell Computers and Humans Apart". These tests don't fulfill that requirement.
Random guessing gives you 3%, which is worse than random guessing on either the MSFT or reCAPTCHA.
This is far worse though. A simple loop over the 30 positions, running the output through an OCR engine would give you nearly 100%.
FWIW, I wrote the paper and AFAIK was the first person to break reCAPTCHA. I worked on the original MSFT Passport/Hotmail CAPTCHA system and improved MySpace's CAPTCHA which took spammer registrations from ~1,000,000/day (automated) to a few thousand (manual) in late 2007.
What do you mean by 'some of the best'? If a CAPTCHA can be solved or guessed in an automated fashion then attackers can just throw more (likely compromised) machines at the problem at little cost. 3% is awful.